I have two Node.js web applications. One is an Express application, the other is a Restify Application.
Can I use this cookie-sessions module: https://github.com/expressjs/cookie-session in both applications, so that if a user logs into one of the applications, they will also be logged in to the other application?
Please let me know if this is possible, and if so, tips on implementation would be greatly appreciated.
Cookies are stored in the browser and are sent to the specific server that they correspond to with every request made to that server. Cookies from one server are never sent to another server. When a cookie is created, it is configured to either be sent with all path requests on the server or only one specific path on the server.
If your two applications are on the same server and the cookies in question are set for unrestricted path access (which a session-based cookie normally would be), then the the two applications will see exactly the same cookies. If they are on different servers, then neither will see the cookies of the other and there is nothing you can do server-side to cause the browser to send you cookies that belong to a different domain.
Related
I am new to React, and I believe this is a unique situation.
So, I am creating a React Website create-react-app. When I run npm start, it will run on localhost:3000.
My next requirement is to have Authentication & Authorization (AA). It is already created by another group.
What they give me is a small proxy website. Let's say it runs on localhost:4000.
When I want to go to localhost:3000/Home, I will type localhost:4000/Home.
localhost:4000 will take care of AA, and if everything works out, it will forward to localhost:3000/Home.
The login information is added to Http-Only & Secure cookie by localhost:4000.
My question is how React can access it?
One of the solution is to use react-cookie. But it cannot access Http-Only & Secure cookie.
The workaround is to create another proxy. React with Express
So, I create another proxy at localhost:5000.
The workflow becomes localhost:4000 will handle AA. The result is forwarded to localhost:5000. localhost:5000 will decide if it should forward to localhost:3000 or redirect to error page. It works if my original website doesn't need to use those result cookies.
But React website needs to do some POST calls to a separate website at localhost:9000. React needs to pass the same AA result cookies to that website. If not, it will ask the user to login again.
I cannot change the cookies properties to non Http-Only, or copy them to another place.
So, the question is how to pass those cookies to localhost:9000?
Am I on completely wrong track because I couldn't find any similar posts online.
In short, can React access the header where some information like username is set, and cookies where actual tokens are stored? If not, what's the standard workaround?
Thanks so much.
Trying to work around HTTP-only authorization cookies is a huge security risk, because in this case they could be stolen by third party scripts. Using proxies to bypass this limitation is certainly an inappropriate solution.
You are working in an environment with several services (localhost 3000, 4000, 9000) that share one authentication system. In this case your options are:
1) Make your server (the 3000 one) communicate with other servers on behalf of the client. If your client needs to POST to 9000, let it POST to a special endpoint of 3000. Your server will then query 9000 and return to the client with answer.
In this case you need to establish server-server authentication which is much simpler that client-server. But you have to handle authorization separately - if your clients may have different permissions.
2) If the 4000 server is only source of AAA, make it a single sign-on server then. There are a lot of solutions of this type. OAuth2 and JSON web tokens (JWT) are hot topics nowadays, with advent of microservices.
You could also talk to the team that developed localhost:4000 and ask what their idea was.
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.
The situation
I am writing a Single-Page-Web App (using Angular). Lets call it SPA
Another team-mate is writing some APIs (using Node.js). Lets call is Server
My SPA is to Login to the Server using login/passwd, and do some stuff
My team-mate has decided to use cookies to track the session. Hence, upon a successful login, a http-only cookie is to be set in the web-browser the SPA is loaded in.
The problem
If we put the SPA in the Server's public_html dir, all works well. This, however, makes the SPA as a part of the API code. This breaks our build process, since every version upgrade to the SPA now requires upgrading the API too.
If we host the SPA in a seperate webserver that only serves the static SPA files, I run into CORS issues. Since the SPA comes from a different origin than the APIs it is trying to access, the browser blocks the ajax calls. To overcome this, we will have to set Access-Control-Allow-Origin on the server side appropriately. I also understand that Access-Control-Allow-Credentials:true needs to be set, to instruct the browser to set/send the cookies.
Possible solutions
We create a build process which does a git-pull to the Server's public_html dir every time the SPA gets upgraded. I am trying to avoid this to keep the client and server upgrades separate.
We create a proxy kind of situation, where the Server doesnt store the SPA files, but collects them on-demand from another server that hosts the SPA files. In this case, the web-browser will see the SPA files and subsequent ajax calls from the same origin.
We code the server to set Access-Control-Allow-Origin:* in its responses. Firstly, this is too open and looks insecure. Is it really insecure, or is it just my perception? Also, since we are setting Access-Control-Allow-Credentials:true, Chrome complains Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.. To overcome this, we will have to put exact origins (perhaps using a regex) in the Access-Control-Allow-Origin. This may seriously restrict us from distributing our SPA to users in unknown domains.
For a Server API designer, is Cookie based authentication the recommended way to handle Authentication for SPAs? OAuth2.0 and JWT based Authentication seems to suggest that Cookies based Authentication is not right for SPAs. Any pros/cons?
Kindly comment on the above options, or suggest any others that you may have used. Thanks in advance.
I think the issue is that your terminology is confusing. API is not an server, its an application that lives on a machine that can also be a server. If you make a NodeJS API, I suggest you use a Nginx server as a reverse proxy before it. Assuming you want the Nginx server, API and SPA files all on same machine, you can deploy your API to a directory and your SPA to another directory and have Nginx route the requests accordingly.
So I believe solution 2 is way to go. From there you can easily scale by increasing number of instances(if you use AWS) and load balance them or separate your API into its own application server.
As far as authentication. I have always preferred using Header Authorization with access tokens over cookies for SPA or API request. The idea that each request is self contained and does not require a persistent string kept on the browser is more appealing to me, though you can save access token via local storage.
I would go with either solution 2 or 3.
2: you could set both (webpage and API) on the same server (or use reverse proxies) so that from an outside perspective they share the same origins.
3: in the case of an API, the same origin policy becomes less important. The API is to be consumed by clients that are not part of your web application anyways, no?
I would not see any issue in setting a more lax allow origin header. And by more lax I don't mean wildcard, just add the origin of your webpage. Why do you want to wildcard it?
I'm fairly new to website development. I'm working on a site where the user logs in with username/password, and gets a sessionID from the server in response. This sessionID is sent back to the server (and a new one returned) with each request.
I'd like the site to work properly if the user opens it in multiple tabs or windows. i.e. once logged in at one tab, opening a members-only URL in another tab works without loggin in. (And, logging out in one tab logs out from all.) I see no way of doing this without storing the latest sessionID in a cookie. That way the latest sessionID can be "shared" among all tabs.
However I am starting to read up on cookies, and some of the security threats. I was unaware that cookies were sent with every request. I don't need to send my cookie to the server, ever. The sessionID is added to the xhr request's headers -- not read as a cookie. So I'm wondering if there is a way to disable sending of this cookie. My only purpose for it is to allow multiple tabs/windows in the same browser to share the same session.
I was reading up on the path parameter for cookies. Apparently this can be used to restrict when the cookie is sent to a server? What if I set the path to something that would never be used? Would this prevent the cookie from ever being sent out automatically? I only want to access it from JavaScript.
A coworker has put a lot of safeguards into the server-side of this application, which I won't go into here. So this question is just about what client-side precautions I can and should take, particularly with cookies, for optimal security. If there is a better way to allow a members-only site to work properly with multiple tabs open at once, I'm all ears.
I discovered just now that in HTML 5 there is local storage, which stores key/value pairs much like a cookie, but is not sent with every server request. Since it's supported in every browser except IE 7 and earlier, I'll be switching to this to enable sharing data between tabs when available, and use cookies instead on IE 7 and earlier.
The sessionID is stored in a cookie already there's no need to manage it. Because the HTTP protocol is stateless the only way to maintain state is through a cookie. What happens when you set a session value the server will look up the dictionary of items associated with that cookie id (session Id).
What is meant by stateless is that between requests HTTP does not know if your still alive or have closed your browser. Therefore with each request the browser will attach all cookie values to the request on the domain. SessionId is stored in the cookie automatically when they go to your site. The Server then uses that value to look up anything you've set in the users session.
Depending on which programming language and/or server you're using the session could be handled differently but that's usually abstracted away from the programmer.
Now with respect to sessions, there are a number of different things that make them insecure. For example if an attacker were able to get their hands on your session cookie value they could replay that cookie and take over your session. So sessions aren't a terribly secure way of storing user information. Instead what most people do is create an encrypted cookie value with the users details, the cookie could be a "session cookie" meaning as soon as the user closes their browser window the cookie is thrown away from the browser. The encrypted cookie contains user information and role information as well as some identifier (usually the clients ip address) to verify that the user who is submitting the request is the same user the cookie was issued to. In most programming languages there are tools that help in abstracting that away as well (such as the ASP.NET membership provider model).
Check out some details on the HTTP protocol and HTTP cookies on Wikipedia first
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
http://en.wikipedia.org/wiki/HTTP_cookie
and check out the membership provider model on ASP.NET, it's a really good tool for helping to secure your site.
http://msdn.microsoft.com/en-us/library/sx3h274z(v=vs.100).aspx
Preventing the browser sending cookies seems to defeat the object of using cookies in the first place.
If you don't want the sessionID to be sent with each request, why set the cookie? A better solution would be to use a custom response header that you send from the server to the browser - this will then be under your control and will not be sent automatically with all browser requests. You are using request headers to send your sessionID anyway so you could receive them from the server using a custom header and read this into your JavaScript from each XHR.
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.