There is some app with aiohttp used just for REST.
Front written in React/Redux.
The most part of application is translated on Frontend side.
But there are also message generated by aiohttp on server side (for example messages about form validation).
What's the best practise to handle these messages?
Make all translation on Frontend side?
There is https://github.com/jie/aiohttp_babel
Did not use it yet though
Related
As I found, it is possible to manipulate and change Ajax code in browser console by client. For example, Ajax wants to call a method and pass id to controller. As I mentioned above, how we can secure our code from interference by client?
Thank you all
Security must always be implemented on the server side, because anything you do on the client side can be ignored, overstep, modified, etc very easily. In fact, anyone can use software like Postman to make a completely custom HTML request to any server.
Don't ever rely on any client-side software in terms of security for your server. If you want keep your server safe, then make a safe server.
I am hoping someone can point me in the right direction. I have a CF2021 Server which uses a Node.js websocket server and CF pages (via javascript) as a client. Messages from user to user work as expected, so no issue there.
This CF Server also has a custom API built using CFML that handles and routes inbound SMS messages. My question is; what would be the best way to send the SMS message (by now its json) to the Node.js websocket to it can send it to the user(s).
I tried using the same javascript that the browser client uses, but it appears that the CFML API script is "browser-less", so that doesn't work, or should it?
I thought something like Apache Groovy may be the solution, but I am having difficulties with any websocket example I have found.
Any suggestions would be greatly appreciated.
thanks in advance
Flow matters.
If you want to handle an incoming message by delivering it to all currently logged in users who are subscribed to messages of the current sort: set up your message handler to deliver using lucee/adobe-coldfusion websockets. Be forewarned, Lucee takes some setup time, but once running, it is a great solution.
If you don't need immediate delivery, or you need a super simple solution: I actually have had some success with "Long Polling" you just have to remember to use "flush" early in the request, before any pause/sleep, then loop your message lookup requests for new data, with a 1-5 second delay between each loop. Once new data is found, I like to return the request to the client, close that polling request and start a new polling request using the client side. I typically won't poll for more than 60 seconds. Even if the returned json object is empty.
At first, I intend to get the validation done on the client side by javascript or jquery, something like that, but then I realize that some malicious users may skip my jsp page, sending data which is not been validated to my servlet. My server end is structured using Spring+SpringMVC+mybatis, is there any way that I can keep the validation on client side, as well as keep my server safe(does spring security help?).Thanks a lot!
You should always validate on the server side.
Validation on the client side is only for convenience of your (honest) users and adds nothing to the security of your system.
The server-side validation must always be done and nothing will make your server automatically safe (safe from what? you have to decide what input is safe for your application, your database, your users, how it will be used etc.).
The only easy way to reuse your client-side validation code on the server side is to use Node.js or other server-side JavaScript like Rhino.
Unfortunately not, you need to validate server side to keep it safe.
Any thing you do client side can be undone by a malicious user. Generally, client side validation is used for quicker feedback to the user and to prevent your server getting too many hits. So it is still very beneficial, but you will need both.
As an alternative to Socket.io, there is SockJS (https://github.com/sockjs/sockjs-client), which seems to be better maintained and more stable than Socket.io.
This question is about the conceptual understanding the architecture of using SockJS with a web framework, say, for building a chat application
My current understanding is that you need the SockJS-client and a SocketJS server (in my case, I intend to use SockJS-Tornado (https://github.com/MrJoes/sockjs-tornado)) to be able to make websockets-style communication.
But how does SockJS (SockJS-client + SockJS-Tornado) tie together with a web framework that does the rest of the work (e.g. serving the page, writing/reading to/from db, etc). For instance, how would SockJS-Tornado component communicates with the web server of the framework? In particular, any direction of doing this with web2py (a python web framework) is highly appreciated.
You're right, for SockJS you need a sockjs-capable server and a in-browser javascript client library.
There are generally two integration patterns, let's say you want to use sockjs-tornado:
You may have all your site served from Tornado. With that, hook sockjs-tornado to some path, for example 'http://mysite.com/sockjs'. In this scenario both your website and sockjs will be served from mysite.com domain.
You may keep your site in whatever language/framework it's written and add sockjs-serveras another compontent, under a different domain, like. 'http://sockjs.mysite.com/sockjs'.
Additionally, you may use any variation of this - for example: have two servers internally but expose them as one domain by using a smart loadblancer (like haproxy).
If you're using web2py as a framework you could look a comet_messaging.py in gluon/contrib. It provides a function (comet_send) for getting messages from web2py app out to your websocket clients. It is based on tornado (w/o SockJS support) but the DistributeHandler can subclass a SockJS connection to provide fallback transport support. In this approach your clients send messages via typical GET or POST HTTP requests which are handled by web2py controllers (or other framework) and receive messages from the web2py controllers calling comet_messaging.comet_send() which sends a post request to the tornado instance which then blasts it out to its list of listeners.
The modified lines in comet_messaging look like (Notice open becomes on_open):
class DistributeHandler(sockjs.tornado.SockJSConnection):
def on_open(self, r):
group,token,name = [None, None, None]
self.group = group or 'default'
self.token = token or 'none'
self.name = name or 'anonymous'
and
urls=[
(r'/', PostHandler),
(r'/token', TokenHandler),
(r'/realtime', DistributeHandler)]
Notice I had to remove the regex group in the DistributeHandler URLSpec because sockJS-tornado was choking on it. Still trying to figure out how get parameters from the path to the on_open handler.
This provides a full answer on how to integrate SockJS into Django: https://stackoverflow.com/a/10950702/675065
Basically you need:
Tornado + SockJS-Tornado
Redis + Brukva
I use this configuration in my own project and it works pretty well.
Or: You try the autobahn way: http://autobahn.ws/ (i didn't try it out yet)
I am working on a J2EE web application
Here we are using JSP and Struts
I know one can use
Client side validation (Using JavaScript)
Server side validation (Using Validation framework)
My question is which way is more proper and one should use in application and why?
You have to use both.
Server side validation is required so that nobody can use malformed queries and gain access to your data. You must do server side validation because anybody can submit malformed queries to your page directly (rather than going through your client side scripts)
Client side validation is only to help innocent users submit correct data in case they were making a mistake which would have cost an entire trip to the server and a page reload to be detected and displayed otherwise.