I'm working on a project which is using PassportJS Google OAuth 2.0. When I test on my local machine (with a React client on localhost:3000 and a Express server on localhost:4000), the flow works fine. I am able to send requests to the server and deserialize the user on each request. However, when I host the client on Google Firebase Hosting and the server on Heroku, the user no longer get deserialized on each request.
Here are some specifics of the things I've done / tried / worked locally along with extra information:
The client and server and hosted on different domains.
I am using axios to send the request to the server. In the request, I make sure to set the "withCredentials" property in the options to true to make sure the cookies connected to that domain are sent on each request.
On the server I have CORS enabled for the domain the client is hosted on (as it is currently being hosted on a different domain) and I have "credentials" set to true to allow the credentials to be sent and received.
Please let me know if I've forgotten to include something in the post or if any extra information would be helpful. Thank you in advance.
I don't know if you fix this, but I got the exact same problem, in my case I added sameSite: "none" in my express session setting, it worked.
cookie: {
sameSite: "none", //add this line
...
},
Related
I've been struggling to find a solution for this issue. Basically I have web application that allows users to sign in with their azure active directory using OpenIdConnect. Everything works perfectly fine on my local. However, when deployed to azure aks, somehow the redirect url changes from https to http when user is authenticated. This causes an exception in azure ad:
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
I defined the redirect URI in the application as https://example.abc.com/signin-oidc and no wonder that it does not match. However, I'm struggling to find out why it's happening and how I can resolve it. I'm using .NET 6 and AKS client version 1.22.
Any help would be greatly appreciated. Thank you
AADSTS50011: The redirect URI 'http://example.abc.com/signin-oidc' specified in the request does not match the redirect URIs configured for the application 'c853f6fe-5f4a-436e-b329-ff6da9ab89ab'. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this.
The above error occurs usually when redirect Url in the authentication are not configured in Azure AD like.
Accessing Website from a different address than what you have defined for your application causes an error.
please check if you have made a mistake in the configuration itself.
From your case :
Please make sure you set ssl redirects url to True
Note:
By default controller redirects HTTP clients to 443 port -https ,if it has TLS is enabled
In ingress routing yaml file if it is set to false, try to set it or modify it to true
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Also as you said you are using .net make sure you have set headers to true.
Please check that header size in 32k in annotations.
nginx.ingress.kubernetes.io/proxy-buffer-size: "32k"
Reference:
Error AADSTS50011 - The reply URL specified in the request does not match the reply URLs configured for the application . - Active Directory | Microsoft Docs
I finally figured out the solution for myself. Thanks to the answer in other SOF
Since I'm using .NET 6, all I have to do is
Set the ASPNETCORE_FORWARDEDHEADERS_ENABLED = true AND
Add these two lines suggested from #Venkatesan to my ingress yml
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/use-regex: "true"
Everything works perfectly after that.
Thank you everyone.
Backend
I am trying make a JWT cookie based authentication work. I am currently performing the following cookie setting as part of a login route in the backend API.
res.cookie('authCookie', token, {maxAge: 900000, httpOnly: true});
Later when I am auth(ing) any other requests, I am reading off of this cookie and testing it in a passport-jwt strategy.
I have gotten this work in postman - when I perform a login and access a secured route - it works perfectly fine + the cookie is also getting set in postman.
Frontend
Now, I am performing the following call stack in the frontend just to test the working,
axios.post("http://localhost:3001/login", logInParams, config)
.then(result => {
// User is logged in so push them to the respective dashboard
console.log(result);
axios.get("http://localhost:3001/user/profile")
.then(result => {
console.log(result);
})
.catch(err => {
console.log(err);
return;
})
})
.catch(err => {
console.log(err)
return;
});
So basically, I log the user in and that works perfectly fine - I am getting a JSON response as intended, but the call is supposed to set a cookie which it is not and hence the next axios.get call is not returning successfully. Though for some reason I see session cookie and a CSRF cookie. Only this authCookie or the jwt-cookie is not getting set.
Some extra details
I am using cors with default parameters - could this be an error of this? Or is there any changes I have to do with axios? I have seen some answers and being new to MERN I don't really understand them. Does someone know about this or have experienced it and solved it?
Are you running the server from a different port than the one that provides the client (i.e: webpack-dev-server running on localhost:3000 and Express server on localhost:3001)? This looks like a same-site cookie issue. In the latest versions of some browsers such as Chrome cookie setting is being blocked when this one comes from a different origin site. This is due to security concerns; you can learn more about same-site cookies here.
The change made in the browsers is related to the default value they give to a cookie policy property called same-site. The old workaround was treating all the cookies from a different origin as None by default, but last year it changed to consider the same-site policy as Lax when no same-site policy was not explicitly provided by the server. This is a desirable behaviour from the browser because it helps at preventing third party sites making use of the cookie provided by the server, but you can edit it by different ways:
Changing the default same-site policy of your browser settings (the article about same site cookies explains).
Sending a same-site:'None' from the server. Express has a way to do so explaind on its docs. Keep in mind browsers also have a new policy to ignore same-site:'None' when the cookie is not marked as Secure, what demands the use of HTTPS (I guess this behaviour can be edited in your browser settings if you want to check while using HTTP).
Obviously, any strategy that demands the users to change their browser settings is a no-go, so running HTTPS with Secure cookies is mandatory for same-site:'None'.
You always have the approach of making both browser and client same origin, so you won't have any issues at all with same-site (i.e. the Express server returning the index.html of the production build of your client as its main static). I haven't found any way to configure CORS module to have a default same site cookies policy (or its sole use as middleware to change it), likely not its purpose, but you can try by adding a dynamic origin config.
As far as I've seen, Postman does not support the same-site cookie property yet, so that would explain why is it working on Postman but not on the browser.
From the looks of it - it seems to be an issue with how cors works and I am adding the following answer to help anyone else coming across it. Thank me later :)
Server Side
You will have a cors in your server that looks like this,
app.use(cors());
You will have to set credentials to true and set the allowedHeaders and origin as follows,
app.use(cors({
credentials: true,
allowedHeaders: ['Content-Type', 'Authorization'],
origin: ['http://localhost:3000']
}));
This is because normally cookies are not allowed to be set in the browser if the server and the client are in the same port. To handle this the above is required on the server side.
Client Side
We also have to pass the cookies when we are sending the request and to do this with axios just add the following in the index.js of your react app as so,
axios.defaults.withCredentials = true;
I think you should write send('cookies are set') at the end in res.cookie('authCookie', token, {maxAge: 900000, httpOnly: true});
I have an express server that has written a cookie, but I can not access it from the client side. I can see it in the Chrome dev tools, it is NOT marked as being httpOnly or Secure, yet when I try to access it via my React app or even just by typing document.cookie in the browser console, I get nothing.
Right now the express server is running on Heroku, and my client side is localhost.
I'm stumped.
Here is my server side code that is setting the cookie:
return res
.status(200)
.cookie('id_token', token, {
httpOnly: false,
path: '/',
secure: false,
maxAge: 400000
})
.json({
token: token
});
Express server is running in heroku and Client server is running in localhost.
The cookie set in the Express server is scoped to the current host when Domain for the cookie isn't set. [1]
Say your application is served at express.herokuapp.com,
scripts can only read it when they're running in the same host. i.e. express.herokuapp.com
However, with cookie scopes cookie set on a domain can be read by scripts running in a subdomain.
In development, you can set Domain attribute for the cookie to be .herokuapp.com
For production, I strongly suggest to explicitly scope the cookie to the client domain. While you can apply the same process as development if client and server are running in different subdomains. You should only do this if other client apps running in other subdomains share cookies.
However if both client and server are going to be running in the same domain, I suggest to keep the default cookies scope.
If client and server are running in different domains, I strongly suggest to explicitly scope the cookie to the client domain.
Then add the following entry in your /etc/hosts to alias localhost to a subdomain of herokuapp.com
127.0.0.1 local.herokuapp.com
Visit the address alias and the client side script will read the cookie.
I am having the following problem. I will describe 3 use cases - two which work and the other one which doesn't.
I have an AngularJS client using SockJS with STOMP. In the backend I have a Spring application. Client is in domain domainA.com, backend is in domainB.com.
var socket = new SockJS(("http://domainB.com/myApp/messages"));
stompClient = Stomp.over(socket);
stompClient.connect('guest', 'guest', function(frame) {
...
}
In the backend there are Cors filters and the Cross-origin calls are possible. All works fine.
Use Case 1. Client domainA, Server domainB
My application is unsecured on the backend side. I subscribe like below:
stompClient.subscribe('/topic/listen', function(message) {
showMessage(JSON.parse(message.body).content);
});
All works fine.
Use Case 2. Client domainB, Server domainB
My application is secured on the backend side with Spring security. Authentication is done through a form - username and password. Nothing uncommon.
In this case the client is on domainB.com, same as the backend. All works fine, the difference is that I use a different subscription method:
stompClient.subscribe('/user/queue/listen', function(message) {
showMessage(JSON.parse(message.body).content);
});
in order to benefit from getting the principal from the security session. All works well. No issues.
The JSESSIONID cookie is added to the connection request in new SockJS(("http://domainB.com/myApp/messages"));.
Use Case 3. Client domainA, Server domainB
The application is secured the same as in UC2. However, the client is now on a different domain.
The JSESSIONID is NOT added to the connection request. The connection to websocket in Spring is unauthenticated and redirected back to login page. This repeats and makes it impossible to connect.
Why is the JSESSIONID cookie not populated with the websocket requests in this case?
Cheers
Adam
As part of SockJS protocol, a http GET is sent to websocket server for negotiating the supported protocols. It's done using XmlHttpRequest which won't add any cookies stored for a different domain than its own domain the web application and scripts are served due to same-origin policy implemented in every modern web browser.
You should resort to a way of circumventing the same-origin policy.
I think you'll find the answers you are looking for here : http://spring.io/blog/2014/09/16/preview-spring-security-websocket-support-sessions
the trick to implement a HandshakeInterceptor
I'd like to use the URL fetch service for app engine (java). I'm just sending a POST to one of my own servers from a servlet.
AppEngine -> post-to: https://www.myotherserver.com/scripts/log.php
I'm reading the url fetch doc:
Secure Connections and HTTPS
An app can fetch a URL with the HTTPS method to connect to secure servers. Request and response data are transmitted over the network in encrypted form.
The proxy the URL Fetch service uses cannot authenticate the host it is contacting. Because there is no certificate trust chain, the proxy accepts all certificates, including self-signed certificates. The proxy server cannot detect "man in the middle" attacks between App Engine and the remote host when using HTTPS.
I don't understand - the first paragraph makesit sound like everything that goes from the servlet on app engine, to my php script is going to be secure if I use https. The second paragraph makes it sound like the opposite, that it won't actually be secure. Which is it?
Thanks
There are two things HTTPS does for you. One is to encrypt your data so that as it travels over the internet, through various routers and switches, no one can peek at it. The second thing HTTPS does is authenticate that you are actually talking to a certain server. This is the part App Engine can't do. If you were trying to connect to www.myotherserver.com, it is possible that some bad guy named bob could intercept your connection, and pretend to be www.myotherserver.com. Everything you sent to bob would be encrypted on it's way to bob, but bob himself would be able to get the unencrypted data.
In your case, it sounds like you control both the sending server and the destination server, so you could encrypt your data with a shared secret to protect against this possibility.
The UrlFetch through https has been fixed allowing certificate server validation.
validate_certificate
A value of True instructs the application to send a request to the
server only if the certificate is
valid and signed by a trusted CA, and
also includes a hostname that matches
the certificate. A value of False
instructs the application to perform
no certificate validation. A value of
None defaults to the underlying
implementation of URL Fetch. The
underlying implementation currently
defaults to False, but will default to
True in the near future.