I am building a react web application with a separate back-end express api that manages all the calls, including passporting and setting cookies. Let's call the back-end service 'api.com' and the front-end service 'react.com'. I'm using passporting with an existing provider (spotify) and after the authorization succeeds, a cookie is set on api.com. The idea is that the user interacts with react.com and requests are made to api.com via a proxy.
If I'm just testing in my browser and I make a call to api.com/resource, the cookie is automatically set. I know this because I've added a bit of logging and also because the requests that require authorization are succeeding via the cookie.
However, when I make calls to api.com from react.com via the proxy, the cookie is not set. Is this expected behavior when proxying? It seems odd that the cookie is set when I call api.com directly, but it is not set when it is redirected. Is there a way around this? My thought would be to communicate the cookie from api.com to react.com, save it there, and send it on all subsequent requests, but that seems overkill. I'm also wondering if maybe I should be setting the cookie on react.com instead of api.com.
I've tried in both Firefox and Chrome, and if it makes a difference, I'm using axios for the requests on react.com.
const request = axios({
method:'get',
url:'/api/resource'
});
This gets proxied as follows (still on react.com), using express-http-proxy:
app.use('/', proxy('api.com', {
filter: (req) => {
return (req.path.indexOf('/api') === 0);
}
}));
But once this hits api.com, any authentication fails, because the cookie is not present.
Any help is appreciated
As far as I have understood your question, I think you're not considering that cookies are set to host name.
So in the first case the hostname is same and its okay, but in the second case the browser's cookies are not set for react.com
So trying to set the cookie on react.com should work.
I would have asked for a clarification using a comment but I don't have enough reputation for that yet.
Related
I'm setting 2 cookies in response from backend to the browser.
One that is secure HTTPOnly (it's refreshToken) and the other one without those parameters so it's accessible to JavaScript (carrying information about refreshToken is set and when it expires).
Cookies in response:
Neither of those two is set in browser. I studied all about cookies and I'll be honest, I'm lost here and need your help.
At first it was working very well on my localhost environment (backend on localhost:8080, frontend on localhost:3000).
Then I made deploy and there it was NOT working.
I tested again on localhost and I checked "Disable cache" to prevent unwanted behaviour and it is not working even there.
I'll mention that I'm using CORS, not sure if that can may interfere:
I tested this both in Chrome and Firefox.
I FINALY figured it out. Cookies are valid. The answer is to set withCredentials = true both in frontend and backend.
First I thought the parameter withCredentials on frontend is used only when we want to send our credentials hidden in secure HttpOnly cookies to which we don't have access to but browser does.
Apparently it is also used when we want to set cookies from response. Link to docs.
responses from a different domain cannot set cookie values for their own domain unless withCredentials is set to true before making the request
Secondly, we also have to add withCredentials on backend to CorsFilter (in Spring boot) otherwise we get CORS error.
CorsConfiguration()
.apply {
allowedOrigins = listOf(uiUrl)
allowedHeaders = listOf("*")
allowedMethods = listOf("*")
allowCredentials = true
}
I have a MERN app whose backend is hosted on Heroku and frontend on netlify. I am not able to see the cookies in the browser after deploying the app but it works fine on localhost. I think it is due to different backend and frontend ports, what am I missing, please help
You are correct. Cookies are not cross-domain compatible. If it was, it would be a serious security issue. The easiest way to fix your problem would be to send back the cookie as a res object, and then setting the cookie manually in the frontend.
Take this for example. I'll do this with JavaScript style pseudocode. Don't copy paste this as this most likely wouldn't work right away. This is what you're going to do on the back-end:
// 1. Authenticate the user.
const userData = await authenticateUser();
const userToken = await verifyUser(userData);
// 2. Return the response object.
return response.status(200).json({
status: 'success',
data: userData,
token: userToken,
});
In the front-end:
const response = await axios.post(...); // your API call, will return above object.
// set your authentication token here.
// the 'options' object will contain all possible cookie options, example would be 'secure'.
cookies.set('token', response.data.token, options);
// alternatively, set the cookie in the local storage.
localStorage.setItem('token', response.data.token);
You need to set the cookie accordingly in the front-end.
Further reading: MDN Docs
EDIT: Your question is unclear. First time you talked about cookies, but now you're talking about httpOnly cookies. Please be more specific in your questions.
It is impossible to set httpOnly cookies in React.js if it is cross-domain. React is only responsible for the 'view' of the website. httpOnly cookies are only meant to be set server-side. Client-side JavaScript cannot read or set that specific cookie, but it is able to send it. Unless you have something in your Netlify that can do server-side operations, I don't think that is possible.
Your best bet is to actually just use the same domain.
I have a web application with react in front-end and node in backend.
I am using passport authentication with passport-saml strategy. Since the last browser update i am seeing an issue. Once I try to login I was taken to the authentication page and it returned back to app page again, then auth page and this continues. looks like i was in a redirection loop.
Once I disabled the samesite attribute flag in chrome then the issue got resolved.
I read some articles and realized that the samesite attribute is causing this. (please correct me if i am wrong. Also want to know), where we will be adding this in backend.. I was using node express session module and addded a cookie object as :-
cookie: {sameSite: 'none', secure: true}
Can someone please help me to find a solution for this?
Is you application behind proxy server with ssl enabled?
I had a similar problem with similar setup and similar symptoms, but I've already switched from saml to oauth (without using passport), so I'm not sure if this helps you.
Anyway, there were two things I needed to do to keep a session cookie 'alive' over the requests.
Set 'trust proxy' in your server code: app.set('trust proxy', 1)
Set X-Forwarded-Proto header to proxy server config (mine is nginx):
location / {
proxy_set_header X-Forwarded-Proto $scheme;
...
}
I'm not sure this is your case, but I'm assuming your app is deployed (I haven't faced this issue in localhost, so your problem may be somewhere else) and your session is being set.
After 3 days trying to figure It out. I finally found a way around this issue, It's not a fix, I'm quite sure PassportJS will come with a solution for that eventually, but for now It allowed me to get the user from the authentication.
Since we are not being able to get the user from the cookie, but the information is in the server session, the way to get this information is to add to the 'server.js' a route to get the user directly from the server session:
app.get('/api/getUser', (req, res) => {
res.json(req.session.user);
});
For some reason, I suppose the lack of cookie somehow, using the req.session inside of a router is returning undefined, but If used inside 'server.js' (or your server index file) It gets the session.
If you need the req.user._id or some other sensitive information for other requests, I would recommend returning a jwtToken with this information to the frontend (in res.json), then save the token directly in localStorage and pass the token in the body of your requests, is not the ideal, but It's the safer way I could think to keep the ids safe.
Okay, so atm i have a frontend application built with Nuxt JS using Axios to do requests to my REST API(separate).
If a user does a search on the website the API URL is visible in XMLHttprequests so everyone could use the API if they want to.
What is the best way of making it so that only users that search through my website gets access to the API and people that just directly to the URL gets denied. I suppose using some sort of token system, but what is the best way to do it? JWT? (Users never log in so there is no "authentication")
Thanks!
IMO, you CANNOT block other illegal clients accessing your
backend as you describe that the official client and other illegal have the same knowledge about your backend.
But you can make it harder for illegal clients to accessing your backend through some approach such as POST all requests, special keys in header, 30-minutes-changed token in header and server-side API throttling by client IP.
If the security of the search API is really important, authenticate it by login; if not, just let it go since it is not in your critical path. Let's focus on other important things.
I'm in the same "boat" and my current setup is actually in VueJs but before even come to StackOverflow I developed a way to actually, the frontend calls the server and then the server calls the API, so in the browser, you will only see calls to the server layer that, the only constraint is that the call must come from the same hostname.
backend is handled with expressJs and frontend with VueJs
// protect /api calls to only be originated from 'process.env.API_ALLOW_HOST'
app.use(api.allowOnlySameDomainRequests());
...
const allowHostname = process.env.API_ALLOW_HOST ||'localhost';
exports.api = {
...
allowOnlySameDomainRequests: (req, res, next) => {
if(req.url.startsWith('/api') && req.hostname === allowHostname) {
// an /api call, only if request is the same
return next();
} else if (!req.url.startsWith('/api')) {
// not an /api call
return next();
}
return res.redirect('/error?code=401');
},
...
};
In our case, we use Oauth2 (Google sign through passportJs) to log in the user, I always have a user id that was given by the OAuth2 successful redirect and that user id is passed to the API in a header, together with the apikey... in the server I check for that userid permissions and I allow or not the action to be executed.
But even I was trying to find something better. I've seen several javascript frontend apps using calls to their backend but they use Bearer tokens.
As a curious user, you would see the paths to all the API and how they are composed, but in my case, you only see calls to the expressJs backend, and only there I forward to the real API... I don't know if that's just "more work", but seemed a bit more "secure" to approach the problem this way.
I am following all the suggestions online about how to send a cookie in an HTTP response in Express.
The simple way would be like so:
app.use(function(req,res,next){
res.cookie('foo', 'bar');
});
however when future requests come to the server from the same web browser, the cookie is not available in req.cookies; in other words, req.cookies['foo'] is undefined.
I have set the front-end code to use "withCredentials" for any AJAX request. Yet the cookie is still not sent to the server, or at least does not appear to be in any way.
One thing that concerns me is that when I call res.cookie('foo','bar') on the server it doesn't show up on the res object/stream as you can see here:
https://www.dropbox.com/s/fe317re9g2frucv/Screenshot%202016-01-21%2023.49.45.png?dl=0
Is there anything obvious that I am doing wrong?