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.
Related
My question is simple. How do I securely share laravel session information with my socket.io nodejs app. I've tried many different methods, none of them worked so I'm hoping a expert will pull through. I already know I don’t want to use JWT Tokens. So I guess that just leaves the session cookie data itself. I cannot figure out how to authenticate socket.io with the cookie so that’s what I need help with. I am storing sessions using redis, and using the default authentication system with laravel.
I’ve tried using this library which is great for parsing the session. But it does not authenticate with my socket.io server.
https://www.npmjs.com/package/node-laravel-session
If anyone knows how to fix this problem I would greatly appreciate some help.
I think, you have problem with authentication problem inside socket.io, idea is that you can't share the session from application to application easily, why? because this data is processed between the client's browser (cookie) and the server ( session ), if you want to connect Laravel and Socket.io, first you have to make some kind of flow like:
When user authenticates on website, to set cookie for socket.io as
well (if host is different).
In background you have to share the session data trough database (memcached, redis etc), and with cookie. As you know, if you set laravel session param to work with database, instead of using files, laravel will automatically start saving session data into DB, so it's easy to read the session params from database.
I think you are using node-laravel-session by wrong, I mean if you have node.js application on other server and you use getSessionFromFile, it will not work. make sure you are using it correctly and it'll work. It's easy process itself to make thing like that, but mostly problem is security when you have cross-project sessions.
Overview: I am trying to understand the interactions between OAuth security in my server and in my chrome extension. I think I have 90% of the answer working, but I'm missing a bit. I'd like to find the cleanest way to finish my implementation using existing tools, rather than reinventing any wheels.
Background: I have a node.js app that uses passport, passport-google-auth, and express-session to authenticate users. I save per-user information, keyed by the user's Google identity. This works fine. My web pages can exchange data with the app, and the Google login screen pops up correctly in exactly the cases I'd expect.
I also have a chrome extension, which includes a browser_action popup that needs to write data to my node.js app and a content_script that needs to read data from my app.
My extension already uses chrome.identity.getAuthToken to get the user identity.
For testing, if I ignore security, I can pass this id to my node.js app, and access the info I need.
But, this is no good, of course. I want my node.js API to be locked down, only letting in clients that have the cookie generated for me by passport.
Side note: I imagine, instead, that I could do some song-and-dance wheel reinvention and pass the id securely to my server via https. But this seems completely wrong, right?
Question: I assume that my chrome extension really should be doing the OAuth2 dance directly with my node.js app. But, I don't know what piece I should be using, or how to cleanly play with chrome.identity. I suspect that I'm just missing a small bit of wisdom, but I don't know what it is.
Side comment: Because cookies are shared between browser tabs, I can (clumsily) achieve what I want by simply connecting to my node.js app from another tab in the browser. So, I guess I just need to get the same behavior from my extension background page.
It looks like the easiest answer for me was to use the Stormpath APIs for this. It took some effort, but was reasonably straightforward.
I have a Node.js server with socket.io. Many domains will communicate with this node server.
I need a way to create a cookie with the domain as my node.js server so that, when a client my node.js server can access this cookie.
This is for identifying the clients on reloads or page navigation with in the domain.
I have searched a lot for this, but couldn't find a solution. I have seen many people leveraging authorization event. I am afraid I don't know when this gets triggered and the call backs. I am unsure if this can sent a cookie back to the client.
If you need any more information, please let me know.
I'm currently searching the best way for developing my next webapplication. I'm thinking about using Backbone.js and build a single page application. But I really can't imagine how to secure my app since nearly everything is done on client side. Of course I just could prevent the users from accessing my RESTful Api so they would not have access to my data. But all the view/model/collection/template js files are still accessible.
Or is there a known way to serve the js files with php (laravel), which would allow me to only serve the files I need for the respective user.
I just couldn't find a solution by searching the Web. But I just don't think that I am the lonely person who needs a clean and secure authentication method including different user rights.
Thank you in advance!
Your backend application will fetch data from a backend (= API), and probably send back some changes.
This code can't have "security holes / leaks" as long as your backend is secured.
If you are afraid of people stealing your code, you can always minify the JS (check grunt.js and almond.js for this)
To secure your backend you can make use of Laravel's auth class, and the auth filter as mentioned before.
Besides normal auth, you could implement roles, that you can assign to specific users, giving them more or less access to certain resources in your backend.
Here's the method I would try :
Separate the application in two parts.
One part - login via regular Laravel Auth on a separate page, and then when the user is logged in serve the single page app in a different view.
Wouldn't this work?
Web Services are no different than any other web application you build. At the end of the day you are exposing functionality to the client (which is also the attacker). It doesn't matter what the client is implemented in, if you expose dangerous functionality you will be hacked.
Have a session state, keep track of the user id and make sure that the user is only accessing resources they have been allowed to access.
I do not think that what JS/template files are exposed really matters. Essentially, you should only be allowing data interaction to authenticated users. Think of this as two separate applications.
The front-end application logs in, and a cookie is stored (or some other persistence is used).
The back-end application then uses the persistent authentication to validate every single user request for data, and every user action.
This way you don't have to worry about the security, the client can only fetch the data that the server allows it to, and, likewise, it can only interact with the data insofar as the server allows it. You shouldn't be relying on the client side for security anyway, even logged in, otherwise some malicious user could, conceivably, save all your frontend code and use it against you without authentication.
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.