I want to set/remove a cookie on react web app when client switches between modes. I want the cookie to be sent with every request to the API which is using django rest framework, and use the value of the cookie to determine the kind of response. The web app and API are in different domains. I'm using react-cookie library to set the cookie which works fine on localhost but having issues setting it in other domains and will only let me use current domain for the cookie.
setCookie('is_test',true,{domain:document.domain.match(/.[^.]*\.[^.]*$/)?.[0]||document.domain,path:'/'})}
Thats the code I'm using to set the cookie, the regex is something I found to remove the subdomain (ex. www.testdomain.com converts to .testdomain.com) if there is any or just set the domain if its something like localhost
but when it is deployed to the actual domain the cookie doesn't get set. Also will the backend API read the cookie if the domain is set with the client domain or does it need to be the server domain that is used for the request. It doesn't let me use other domains outside of the current(client) domain
Related
I have the following setup:
ReactJS PWA frontend application that uses service workers to cache the source code to the client.
ExpressJS Reverse Proxy which relays any request that would go to a backed API. This handles a login process and stores a token on the server and sends a session cookie to the client. The cookie is HtttpOnly, SameSite, Secure and signed. The proxy also checks if the connection is secure, referrer is in white list and exact match and same for the host.
Backend API is on a different server with OAuth login protection.
Express returns a server side rendered page on the first load then ReactJS hydrates that page and uses as an SPA. Every file afterwards is cached into the browser.
Every request that comes from the client app is handled with the same token as they are not user specific operations. User specific operations require e-mail and password to get a new unique token from the API.
My issue is:
An attacker could create a cookie and send it along with a curl request to the proxy. This would by pass my ReactJS app as both referrer and host can be faked.
I would like to find out how can is secure the connection between the ExpressJS proxy and the ReactJS PWA.
I was thinking about CSRF with csurf but that would not work. If the PWA is installed on a phone's as an app, then it would only access the Proxy when the request is sending. Therefore I cannot set the CSRF header.
If I was to add the CSRF token to the very first request when the client hits the server and the page is rendered with SSR, I would only set the token only once, which can be re used as many times as the attacker wants.
Is there a proper way to lock the proxy to the app somehow?
I cannot store anything in Local storage and I cannot hard code tokens into the source code of the app. (They are insecure options)
Thanks!
I'm implementing login functionality on my site and I'm running into some problems when sending jwt tokens as cookies.
When the user logs in on the frontend, a POST request is sent with "credentials: 'include'" (I'm using fetch) to my backend API, which returns a jwt token if the login was successful. This all works fine, and I can see the cookie in chrome dev tools, and performing actions that require authentication work fine.
However, when I refresh the site, the jwt cookies disappear. I have ruled out errors with expiration. Through experimentation I've figured out that the domain is the problem. The cookie's domain is "127.0.0.1" from the locally hosted instance of the API, which is different than the domain of the locally hosted website. If I manually change the domain of the cookie to the same as the website, the cookie doesn't disappear.
But that does not solve my problem permanently, as the backend API is hosted on a different domain than the frontend. I've been reading up on cross-domain requests but I'm not sure how to proceed from here. I control both the frontend and the backend, but I'm starting to wonder if I might be going about this the wrong way? Would the simplest solution be to host my api on, say 'api.mydomain.com' instead?
I have a GAE app set up to use a custom domain, let's call it mycustomdomain. This naked domain is working fine over HTTP and HTTPS. I also have a service called api, it can be accessed successfully by going to http://api.mycustomdomain.com (custom domain convention).
However, I can't access the api service over HTTPS. I uploaded a SSL for mycustomdomain.com, but I got an error (site can't be reached) for trying to accessing the api service over HTTPS. My question is do I need to purchase the wildcard.mycustomdomain.com SSL in order to access the api service over HTTPS? I don't have much experience dealing with SSL certs and GAE custom domain, so any help would be greatly appreciated. Thank you!
Edit: updated information for GCP Console configurations.
My app setup in the Console contains the following:
Services: default, api
Custom domain setup: mycustomdomain.com
SSL uploaded: ultrahdlivewallpaper.com (NOT the wildcard version), api.ultrahdlivewallpaper.com (unable to be enabled for custom domain, none matching)
More detail: The problem is when I map both ultrahdlivewallpapers.com and api.ultrahdlivewallpapers.com, they are both mapped to the default service. I want api. to point to the API service. If I only map ultrahdlivewallpapers.com, that allows me to access api service at the api subdomain, but then the api SSL can't be applied to api. subdomain because it's not listed as a subdomain.
07/24/17 Update: I believe this is a limitation with the App Engine Settings after trying out several scenarios via GAE Console. We have a custom domain set up for ultrahdlivewallpapers.com and enabled the SSL cert for this domain. The domain is pointing to the default service. We have a second service set up called API. Google's routing rules for any service set up is via HTTP:// service-id.custom-domain, which in our case is api.ultrahdlivewallpapers.com. However, when I upload the SSL for the api subdomain, Console couldn't find matching domains because the api subdomain is not specified via the Console. Now if I set up api.ultrahdlivewallpapers.com as a custom domain, I'm able to enable the SSL for api subdomain. Problem then becomes api subdomain is now pointing to the default service instead of the api service. If I remove the api mapping, I'm able to browse to the api service again, but no HTTPS! I don't believe there is a way to get this set up correctly without a wildcard SSL enabled for all subdomains. Please let me know if I'm missing anything. I have tried everything I can think of via the Console. Thanks.
You don't necessarily need a "wildcard" cert, per se. But, you do need to get a cert that covers all the subdomains. For example:
mycustomdomain.com
www.mycustomdomain.com
api.mycustomdomain.com
It's a standard solution, and not difficult to do. Certbot (Let's Encrypt) makes it easy.
If you choose to get a wildcard certificate installation is pretty straight forward:
You upload the certificate in the developer console (in App Engine -> Settings -> SSL Certificates -> Upload a new certificate). May require a bit of effort, see also Google App Engine SSL with Let's Encrypt "could not be inserted".
Once it's visible in the certificate table you can click on its name and you'll end up in the certificate edit screen where you can select which custom (sub)domains it applies to (from the list of all custom domains mapped in the app), looks like this:
Note: these are the corresponding custom domain mappings:
If you have another app (under the same admin account) which is also mapped to subdomains of the same domain you can activate the certificate on it as well in a similar manner (the console automatically shows the certificate in the list when you switch apps, no need to upload it again).
I have two apps.
Front end - AngularJS website running on localhost:9000 and getting data from rest service (database)
Back end - Spring Boot Rest Service localhost:8080
How to create authenticate process for this two app? Login from (user, password). I reading some tutorials on spring website, but front end are build in spring project on the /resouce folder, not separated.
There are a couple of things you need to keep in mind if you are setting up your app the way you want to.
What kind of authentication mechanism do you want? For rest services Basic and oAuth2 are most common.
With Basic auth you would send authorization header in each request.
Each request will perform authentication all over again.
There is no state between client and server
Https is mandatory if you use basic auth.
With oAuth2 first you need to send basic authentication request to end point your.app/oauth/token? --- parameters
Response will contain
access_token": "CQPt2VR2HJuCY3mb0xA1BVMyDltgvnpf6N2CXdsds3423YkGQID7VO-Mmu4idymlz"
Which you then include in every request with bearer token :
Authorization Bearer CQPt2VR2HJuCY3mb0xA1BVMyDltgvnpf6N2CXVPXkaewYkGQID7VO-Mmu4idymlz
access_token has an expiration time. You can also send refresh_token which has longer expiration time.
There is no state between client and server
For smaller applications oAuth2 is too complicated and basic will suffice.
This is just an overview of common authentication methods. There are a lot of implementation tutorials. Example : https://spring.io/guides/tutorials/spring-boot-oauth2/ and http://www.baeldung.com/rest-api-spring-oauth2-angularjs
One thing to keep in mind is you will need to setup CORS filter. If you run your service and client on different ports. For starters annotate methods you want to use with #CrossOrigin(origins = "http://localhost:9000") You can of course register global cors filter.
I have an App Engine server hosting an AngularJS application that makes CORS requests to some Cloud Endpoints APIs on another App Engine server. As per the $http service documentation I have enabled it to send credentials in cross-domain requests by settinga default header:
$httpProvider.defaults.withCredentials = true;
The front-end server has an associated custom domain with SSL support, and makes requests via HTTPS (so that both the ends are basically HTTPS).
My goal is sending an authentication cookie to the backend in order to manage resource access authorization, but for some reason this cookie never gets sent.
I do see the cookie in the request when the two servers are running locally (frontend: http://localhost:8081, backend: http://localhost:8080), but not when they're deployed.
What am I missing there?
angular http Documetation i follwed
Try adding this header to your HTTP calls {'Content-Type': 'application/x-www-form-urlencoded'}
If I understand correctly, you want to send an authorization cookie over CORS to a different (sub)domain?
To do this, you need to permit CORS requests on the initial page load, use 'withCredentials' as you have detailed as well as have a cookie for the targeted cross domain call. If it's cross domain, you'll have to write the cookie in js code, if it's a sibling subdomain make sure the cookie domain starts with a dot .domain.com, and the cookie will then be shared across all subdomains of the domain.
Localhost can play havoc with this kind of testing because the domain relationships are different (i.e. Not sibling subdomains) - you can try using a local proxy to set up a scenario which maps subdomains to a loop back address.