I'm trying to call my /auth/user endpoint to get the current user that's logged into my website. But because of the new Chrome update I need to somehow set 'sameSite' and 'secure'. Anyone know of how I can get around this? Am I doing something wrong with cookie-session?
The cookie gets sent by express just fine, but it doesn't come with sameSite and secure settings that I specify in the cookie-session settings (see image). I tried with express-session as well, but for some reason the sameSite and secure settings never propogate to cookie used for oauth.
Btw, the authentication works on localhost addresses, but when I deploy from frontend and backend with heroku, I encounter the issue where I need to set sameSite. Would setting up a proxy or something get around the sameSite issue?
I am working on the same issue. SameSite=None needs the cookie to be secure
https://www.chromestatus.com/feature/5633521622188032
Eventhough I have set "secure: true" I am still seeing the cookie not being created on Chrome, but I do see it on Edge
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.
I hope It can help you!
Related
I have a question regarding the possibility to change the backend occ endpoint for the login.
In the default behavior, an auth object is created in local storage.
I changed in the app.module the default login: '/authorizationserver/oauth/token', to a different endpoint (/ourowntestserver/oath/token/test). After the change, the backend-side works as it has before, but on the front-end side, the auth object is not available in the local storage anymore.
In the Spartacus source code I can see an OAUTH_ENDPOINT with the same endpoint '/authorizationserver/oauth/token', used in an open-id-token.service, but I am not sure if that service is responsible for actually saving the token and if I have to extend it in the storefront app along with its store(actions, effects, etc.) too.
Are there any other changes that have to be done for this to work, or am I doing something wrong? Is it possible that the issue could be still back-end related?
Any help would be appreciated. (edited)
I would start by inspecting ngrx actions in devtools. Look for LoadUserToken and LoadUserTokenSuccess and LoadUserTokenFail actions. Look at their payload if everything there looks ok. Maybe the structure of response is different than the one returned from the default hybris OAuth server. Then you might need to create your own effect and handle the response a bit different than we do this by default.
The OAUTH_ENDPOINT is not currently customizable and it is being fixed right now for the 3.0 release. It'll have new auth module structure and allow for easier replacement of OAuth server.
open-id-token.service.ts is only used with Kyma module when you also need apart from access_token the id_token from OAuth server.
I want to understand whether nuxt-auth uses serverMiddleware and if not how can i implement one. I want to make my admin panel really secured, I have my backend secured however even if someone manages to overcome auth middleware on the frontend, which won't be that difficult(if auth Module uses client-side middlewares), I don't want nuxt to provide him/her with the layout and all pages even though I know that he/she is not going to be able to do anything because my routes on the backed require token verification and account data. If you can, please provide some info on the subject. Thanks!!!
So in short you cannot use the middleware provided by the #nuxtjs/auth plugin as a serverMiddleware, you can only use it as a normal middleware.
But that doesn't mean that it's insecure, normal middlewares actually executes both on server and client side before the page is rendered, so if you want to execute a middleware that will throw a 404 if the user isn't logged in you can do this in a normal middleware too, the serverMiddleware's capabilities are actually limited, you can't access nor the store or any client side information, because you only get (req,res, next) as parameters, and since Authentication is stored in store and cookies you can't make it work in Node.js only. This is a good example of what you can use serverMiddleware for: https://jackwhiting.co.uk/posts/handling-redirects-in-nuxtjs-through-middlware/
If you console.log something in normal middleware you should be able to see it both in your developer console and bash where npm run dev is running, this would mean that first the server executes it and then the client side too.
I am currently using httponly cookie based authentication to authenticate users through a website. On top of this I am creating a react native app which also has to authenticate users, ideally through the same endpoint. At this point users are able to log in through the app and the cookie is correctly send on each subsequent request using credentials: 'include' (fetch). However, if the app is restarted, the cookie does not persist.
So far my searching has led me to the following possible workarounds:
Manage cookies manually by extracting the cookie through something like webview or react-native-cookies, saving the cookie to storage and manually adding it to each subsequent request.
Implement a new endpoint that returns a token and have two authentication flows, one for the website and one for the app.
Have anyone been in a similar situation? Can you point me in the right direction, so not to over complicate my code base and ensure that I am not vulnerable to XSS or other token/cookie theft.
Thanks in advance.
To be honest I never implemented cookie based authentication in react native. How do you handle cookies now ? Basically the flow should be like this:
You authenticate with username and password.
Server will respond with a header "Set-Cookie: sessionIdExample=1234"
Next time when you make a request you should also send that cookie, meaning you have to set a header "Cookie: sessionIdExample=1234"
From your question I guess you don't manually set that cookie, so most probably the http client is doing this for you. Now when you close the app that cookie value is lost as you said. Notice that switching to a token based authentication won't help with this. So what should you do:
Login with username and password.
When you receive that session cookie persist it. You can check async-storage or the more secure react-native-keychain for persisting data.
For the following requests set the session cookie manually.
When you close the app and then open it again, check in your async-storage or keychain if you already have a cookie saved there. If so, set that cookie and everything should work fine.
I've spent the last day or two pulling my hair out over this, so I thought I'd share the answer.
Problem: When trying to get an authentication cookie from the client side (using some http library or another), you get a 401 Unauthorised response. Even though you know the username and password are correct and you're doing it exactly how it's done in all the examples. Well my friend, your issue is that you expect things to make sense.
Turns out that if you have the require_valid_user set to true in the couch db config, and then don't include those credentials with an authentication request (even if the credentials you're authenticating are valid!) couch will reject it out of hand. So you've two options really,
Keep require_valid_user true and do your authentication on your own server where you can wack in the admin username and password as a part of the url (like so url = http://admin:password#url:5984). And then authenticate your credentials and pass back the ensuing cookie you get from that. (Make sure in subsequent requests straight from the client to the db you include withCredentials:true, so the browser sends the cookie with the request).
Say screw it and don't require a valid user with each request, and instead authenticate on the design doc and database security level only. I can't vouch for how secure this is, as I haven't done it.
I'm playing and learning a bit express so I'm doing a Post to a specific route with some data related to my user and I'm trying to create a cookie from the expressJs server and send it back with the response. But unfortunately nothing happened. I'm testing the route with Postman and it's telling me:
No cookies were returned by the server
here's how i'm trying
res.status(200).cookie('rememberme', '1', { expires: new Date(Date.now() + 900000), httpOnly: false }).send('Cookie sent...?');
I'm probably doing or missing something stupid, so what's wrong with that? Any ideas please..?
If you use older version of Postman, the one that runs in the browser, you would be able to see the cookie.
However, the new one doesn't run in the browser anymore, it becomes a seperate chrome app, so it doesn't read browser cookies anymore. In order to see the cookie, you will need to install the postman interceptor