Recently I worked on a project, which is a real time web application.
I use socket.io as the data server, and let's suppose that its domain is www.a.com. On the other hand, I use express as the http server, and its domain is www.b.com.
Now the problem comes, if I want to synchronize the session between two server(that means, if user login www.a.com by socket.io, he/she is logged in when he/she visits www.b.com), how can I do that?
Thanks in advance :)
ps: please forgive my poor English...
== Update ==
I have tried one solution: use the magic of postMessage to communicate between different tabs.
When a user login in www.a.com, I create a iframe, whose src refers to www.b.com. And then I can pass login data from www.a.com to www.b.com, and trigger something to login in www.b.com.
But I think it is not a best way to solve the problem, is it safe? or generate other problem? And I wonder if there are other solutions.
By their nature, cookies (which store session id) can't be read from different domains. I know of a mod for Apache that could encrypt login data from one domain and place it in a GET request (address bar) so the user wouldn't then have to log into a second domain. Sorry, I can't recall what it was called, but you could do something similar, all you'd need is require('crypto') I believe.
EDIT: Why do you want the sockets & web server to run on different domains? If they ran on the same domain, I believe there is a module to allow sockets.io to get the session data. I didn't use it myself, just read about it.
Related
I am trying to set up NGINX so that it redirects a user either based on whether they are logged in or not.
For example, say the site is https://example.com and a user arrives at this URL, if they are not logged in we want to show a marketing page with register actions etc. If they are logged in, we want to send them right into the product. This is the same model as github, bitbucket etc. We don't use a cookie for managing session state, so trying to detect cookie from NGINX is a non starter, that is managed on the server.
So my question is this. Can anyone recommend some recipes for nodeJS and NGINX that could give me some ideas to follow on how to set this up? Do I need to create something specific at the nodeJS end to satisfy NGINX in order to tell it that the user is not logged in? Or can I achieve this with checks in NGINX? I'm trying to protect the application from the outside world as much as possible which is why NGINX is the choice we made.
I've spend quite a few days trying to figure this out and am still as stumped as when I started so any pointers would be greatly appreciated.
Nginx in this case is meant to serve as a reverse-proxy to your Node application. This is a perfectly fine setup. However the functionality you're describing (check if the user is logged in) is something you need to check at the application-level (Node), not the webserver-level (Nginx).
How you will check whether the user is logged in is dependent on your login system, which we don't know anything about other than that it doesn't use cookies (which is in fact a rather common way to do this).
Here I will describe the requirement for my project.
Basically I want to build a chat application which I can embed to different websites for example , site build using wordpress, magento, drupal, custom frameworks ... etc . What I actually need is to embed JavaScript for handling socket chat using (socket.io) on some of the website(wordpress, magento, drupal ....), so what I finally have is a set of javascript code (client side), and a server running in nodejs (with socket.io)
The problem I faced is to manage session for registered users after login. Since my code is embedded on different websites and the node server resides on other server , On each page refresh I faced difficult to validate user session session. Could you please help me how I can manage session in a best way for this application.
If you feel difficulty to understand my need , I can explain in detail with examples
Thanking You
If I understand your problem, you just need to handle user sessions? More specifically on the client side?
Based on the information you give, I will just assume you either return a unique string representing the session on the server to the client. The format of this can either be a cookie, a normal string/token, etc.
For cookies, you shouldn't have much problems, since the browser deals with this. Although you might need to set it up correctly on the server.
For tokens/strings that needs to be returned to the server for each request requiring authentication, you should store it in the session-storage/local storage of the browser, depending on your need. Then you should embed it in every requests back to the server and authenticate it.
I'm implementing the "remember me" functionality for the client of our product and I'm a bit stuck with it. Here what we have:
3 separated servers, which doesn't comunicate each other.
A client which needs "remember me" functionality and which is redirected to one of 3 servers at log in.
That instance, which redirects users, doesn't know anything about authentification or user credentials.
So could you, please, give me some guidline of how can "remember me" implemented in my case? Storing password in cookie is acceptable, but not desirable.
If you need more info about something, please, ask, and I'll try to provide it.
Thanks to everyone for your suggestions!
This is typically done by having all three servers use a common session storage backend, like a database or memcache.
If you can't easily implement common sessions, you could adjust the code on the redirect server to store the server id of the server that it selected to redirect to in a cookie. Don't store the password in a cookie. For example:
new hit comes in
if cookie exists:
forward to the server indicated in cookie
else:
pick a random server
set cookie with the server id you picked
forward to the server you picked
This is a question involving single page web apps and my question is in bold.
WARNING:
I'm hardly an expert on this subject and please correct me if I'm wrong in part of my understanding of how I think HTTP and WebSockets work.
My understanding of how HTTP restful APIs work is that they are stateless. We use tools like connect.session() to interject some type of state into our apps at a higher level. Since every single request is new, we need a way to re-identify ourself to the server, so we create a unique token that gets sent back and forth.
Connect's session middleware solves this for us in a pretty cool way. Drop it into your middleware stack and you have awesome-sauce sessions attached to each request for your entire application. Sprinkle in some handshaking and you can pass that session info to socket.io fairly easily, even more awesome. Use a RedisStore to hold the info to decouple it from your connect/express app and it's even more awesome. We're talking double rainbow awesome here.
So right now you could in theory have a single page application that doesn't depend on connect/sessions because you don't need more than 1 session (initial handshake) when it comes to dealing with websockets. socket.io already gives you easy access to this sessionId, problem solved.
Instead of this authentication work flow:
Get the email and password from a post request.
Query your DB of choice by email to get their password hash.
Compare the hashes.
Redirect to "OK!" or "NOPE!".
If OK, store the session info and let connect.session() handle the rest for the most part.
It now becomes:
Listen for a login event.
Get the email and password from the event callback.
Query your DB of choice by email and get their password hash.
Compare the hashes.
Emit an "OK!" or "NOPE!" event.
If OK, do some stuff I'm not going to think of right now but the same effect should be possible?
What else do we benefit from by using connect? Here's a list of what I commonly use:
logger for dev mode
favicon
bodyparser
static server
passport (an authentication library that depends on connect/express, similar to what everyauth offers)
The code that loads the initial single page app would handle setting up a static server and favicon. Something like passport might be more tricky to implement but certainly not impossible. Everything else that I listed doesn't matter, you could easily implement your own debug logger for websockets.
Right now is there really anything stopping us from having a single http based index.html file that encapsulates a websocket connection and doesn't depend on connect at all? Would socket.io really be able to make that type of application architecture work without setting up your own HTTP restful API if you wanted a single page app while offering cross brower support through its auto-magical fallbacks?
The only real downside at this point is caching results on the client right? Couldn't you incorporate local storage for that? I think creating indexable/crawlable content pages for search engines wouldn't be THAT big of a deal -- you would basically create a tool that creates static html files from your persistent database right?
Check out Derby and SocketStream.
I think what you're asking for is if it is plausible (using socket.io) to create a website that is a single static page with dynamically changing content.
The answer is "yes", it can work. Several node.js web frameworks already do this although I don't know of any that use socket.io.
I am using Sencha Touch for some weeks now, and I plan to add to my webapp, a form with which users can contribute with informations. I was wondering of means of securing this form, since it will directly post entered data through an Ajax call to my server. It will not be too difficult for someone to sniff http traffic and write some script that would kill my database server sending data to my submit server side action.
I was wondering about using recaptcha, but I cannot see how to implement it or neither if someone has tried it. I am open for any other form of security that could be easily implemented in the context of sencha touch
Thx
Create some simple form of captcha if you want. Like addition of two numbers etc.
You wont prevent sniffing http traffic using a captcha, use ssl, if you send your requests using https no one can sniff your trafic.
But even that cannot prevent someone sending a crafted request to your sever trying to exploit it, since they can tell by looking at your client code what is the server expecting.
You can try to obfuscate your client code, but that wont help much either.
The only way to prevent it is by validating the requests on the server side and invalidate all the requests that can potentially harm your system.