The story is, I have 2 potocol in my sails.js server, this sails server is only for API access, and some API are MUST logged-in to access, the websocket is also running on this server.
In the sails when I login then put the user data in req.session.me, this will save the user data in session, next time I through http to access then I can get save data from req.session.me.
Reference: http://sailsjs.com/documentation/concepts/sessions
The question is saving data in user session req.session.me through http to access the server then cannot get back req.session.me through websocket to access the server.
Many Thanks!
Related
Once a user subscribes to push notifications, I get the subscription info in my JavaScript code. I want to send this information to the server for storage to be used for future notifications.
I assume that the endpoint for the AJAX POST request should be public (the website itself is publicly accessible). Should the endpoint be completely open? Should I use some token generated on the server that expires after a certain period of time?
My concern is that, if it's open, it can be used maliciously to post data to my server. Should there be some validation of the data? If so, what kind of validation applies to subscription JSON objects?
What's the best practice for doing this securely (if any)?
I create a simple login/password html5 application. Login/password I send via websocket to server to control and set in server side some permissions etc.
How can I connect to this socket in next pages and server can sending correct data which permissions available etc.
Or this login password have I sending always when I connect to socket in every page?
You can store token/session id in cookie.
On following navigation pages you can send that token to websocket to authenticate. Upon successful authentication you can response.
P.S. you need to create new websocket on every page load.
You can use regular web authentication using cookies.
WebSocket HTTP negotiation will carry cookies over. So you can return a cookie when the user connects with an generated UID if there is no any in the request, and then when the user authenticates, consider that UID as authenticated and associated with a User. Each time you get a connection with that UID you know it is that User.
I'm trying to figure out the best way to authenticate a Firebase request with a server side API endpoint using an existing session held with the user on the client app.
Let's say want an endpoint called generateKey that writes a generated key to a users Firebase profile object that only an authenticated user can write too:
http://example.com/generateKey?id=qwerty123
The user has a pre-existing authenticated session with the target Firebase through the client app. The user needs to generateKey through this endpoint. I could pass the auth.token as a parameter to the API endpoint like:
http://example.com/generateKey?id=qwerty123&token=abc123
And then use ref.authWithCustomToken(TOKEN) in the route handling the API request server side.
This method seems to work but is this the right way to do this?
I work on web application and I want to have live notifications to a user via websockets. These notifications should be received only by a user whose notifications belong to.
I wonder if it's good idea to pass an temporary authentication token (which would be unique for a user) to javascript and the script connects to websocket server and pass the authtoken as a parameter to make a handshake. Is it secure solution to pass auth token to javascript and then login via websocket using this authentication token? Of course web app is secured by ssl and web socket server also.
You can try
User authenticate to Web app Server
Web app Server will generate 1 Key Code for this session ( Maybe Md5 with salt is username) if user are valid
Web app Server send this key to Web Socket server
Web app Server send this key to client-side
Client will send this key to websocket server to authenticate
If socket contained this key -> user is valid -> OK, continue to transfer data between socket and client, Else Web socket server will stop this connection.
It will be secure because authenticate key is unique and SSL will make it be better.
Hope it'll help you. And this was our solution for building a FOREX System : Authenticate via CAS ( Single Sign ON ) and Websocket to send the index data. In our case, CAS server will generate 1 Single Sign On ID, and we use it to validate.
Is it possible to get a session from a server and pass that session cookie to another ip so that one can use it to communicate with the server that issued that session?
session server -> my backend server 1: getting session cookie
my backend server 1 -> my backend server 2: passing session cookie
session server <-> my backend server 2: communicating directly with session server without the middle man.
I'm using CouchDB and Node.js/Javascript.
I tried to send the set-cookie header received from session server (couchdb) to backend server 2 and it did set the session cookie in the browser. But when making requests to couchdb it didn't send that cookie along. I think it's because of it has to be the same ip that it got the session from, in this case, the server 1.
How do I make it work?
Cookies are based on domains, so the browser will only send the cookie back to the domain it was set on.
You get the client to send a request to the second server with data allowing the server to create a new cookie. Not sure what kind of security you need.