So I'm looking at creating a graphic chat application / website (users sit in a room in 2D incarnations and chat ) And what I have researched, so far (a lot!), A lamps stack looks appropriate for most of the site, some nodes are used to send genuine chat data along with js and website protocols (user Messages, etc.). I am not very experienced in making anything of this scope (I am addicted to further end work), but so far it is a fun challenge!
My problem is, I do not think there are so many information about confirming the user's information I have read that the website is naturally insecure and verifying the source of the data being sent. Well ...
My concern, however, is the real identity of the user. If I use Javascript to initiate the socket connection, how do I stop the user from "spoofing" any information? Is it possible to hook a user's PHP session data to tackle webcockets connections, so JavaScript will not handle anything but the actual message text
For example, if I say "Kris" and "Hello ! "Message has changed or changed the image of my avatar, I want to handle the" Hello "or Avatar image URL only to the client side, and forward all the information such as the user on the server side Any person Ta name is wrong with the client-side code.
The question is wide and can not touch any particular challenge, lack of knowledge and experience.
However, I will still comment on some points which may be useful to you:
- WebSocket Security is similar to the HTTP request security - it's up to your application.
- Sticky sessions are required to identify and continue the session from different processes / servers. If you decide to use LAMP (which I would not recommend), then you actually have PHP and A sticky session is required between the nodes. JS process.
- WebSocket (handshaking) during the connection makes general HTTP request with some extra General cookies data can be used on server-side to restore that session and in that session related to the client socket is. After the socket is disconnected, the relationship must be lost.
- Recovering the session using HTTP requests or WebSockets is quite similar in terms of security, because the websocents actually come after the session is restored.
- Multiple tech stacks, proxying nodes via Apache to work from the same domain. There may be reason to complicate with JS. For the application you describe, I do not need this old school + modern stack mix. You can go to ngin.js with ngin.js to serve static files. It will be very easy to work with you, and your code language will be completely in the project and it will be easy to maintain.
- Nodes. It is very easy to use JS, so that it will save time again. The actual logic behind the reset API is to get data for your socket .io directly by your node. JS can be used again if you want too.
- You need the server & lt;> customer official politics for communication, the client only "asks" and makes a decision based on what the server thinks right or wrong and this rule in terms of security Must be # 1. If the client decides who will hack and cheat others.
Again - this is a very broad question and a question of very "talk" style rather than a specific challenge.
Comments
Post a Comment