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.
Related
I'm developing a web app with React and an GraphQL API with Node.js / Express. I would like to make the API more secure so that its harder for API requests that don't come from the web app on the browser to get data. I know how to do it with registered users. But how to make the non-registered user still be able to access some basic data needed for the app?
Is it possible to put some kind of key in the web app - so the API call can't be replicated for others through sniffing the network dev tool in browser and replicating in Postman? Does SSL/TLS also secure requests in that browser tool? Or use like a "standard" user for non-registered visitors?
Its a serverside web app with next.js
I know theres no 100% secure api but maybe its possible to make it harder for unauthorized access.
Edit:
I'm not sure if this is a problem about CSRF because Its not about accessing user data or changing data through malicious websites etc. But its about other people trying to use the website data (all GET requests to API) and can easily build there own web app on top of my api. So no one can easily query my api through simple Postman requests.
The quick answer is no you can't.
If you trying to prevent what can be describe as legit users form accessing your api you can't really do it. they can always fake the same logic and hit your webpage first before abusing the api. if this is what your trying to prevent your best bet is to add rate limiting to the api to prevent a single user from making too many request to your api (I'm the author of ralphi and
express-rate-limit is very popular).
But if you are actually trying to prevent another site form leaching of you and serving content to their users it is actually easier to solve.
Most browsers send Referrer header with the request you can check this header and see that requests are actually coming from users on your own site (this technique is called Leech Protection).
Leaching site can try and proxy request to your api but since they all going to come from the same IP they will hit your rate limiting and he can only serve a few users before being blocked.
One thing the Leecher site can do is try to cache your api so he wont have to make so many requests. if this is a possible case you are back to square one and you might need to manually block his IP once you notice such abuse. I would also check if it's legal cause he might be breaking the law.
Another option similar to Referrer is to use samesite cookies. they will only sent if the request is coming directly from your site. they are probably more reliable than the Referrer but not all browsers actually respect them.
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 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.
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.