I'm working on express server application and there are bunch of api endpoints that I configured. Almost all create and update requests, I need to store requested user's userId in order to keep log. I created a middleware function that verify user JWT access token and retrieve userId from access token payload. In my current situation, I add user info as req.body.loggedUser in req body. I think this is not a good thing to do. I do it like,
req.body.loggedUser = accessTokenPayload.user[0];
This works fine in every POST request. But I need to do it in right way. And also this method cannot use in GET requests. If nodejs can keep temporary variable until a request done its process I can keep log on GET requests also. So all I need to do is keep user info as temporary data until request process done. How I can do it.
Just add it to the req variable:
req.loggedUser = accessTokenPayload.user[0]
This works in GET requests as well
Related
I have an app that recommends gifts to the user, after they answer a couple of questions. In the case that the user likes or dislikes a gift, I need to send an update request to the db to update it's 'liked' field. Users are not required to sign in order to like/dislike questions. The app is built using Angular and used Express at the backend to do the CRUD operations.
My question was, is there any way this operation can be done in a secure way, so that the user can not open the dev tools and get the info which would enable them to send repeated requests or anything like that? Is there anything I can change in the Express code? Or would I need to change the security rules?
Express should have a way to identify duplicate request. User id or some kind of token should be with request. But I see that sign-in of user not required in this case.
You can generate a temporary token every time some gifts are shown to user. This token should be generated and saved temporarily on express and you can send it with gifts data. So now when your frontend send request for like/dislike, this token will be in request.
So now express will do following steps
Checking if temp token is valid (it can match it with saved tokens)
If valid then it will update the database (like/dislike)
After successfully update it will remove that temp token.
So now, even if user send duplicate request it will be rejected by express as temp token will be not valid.
I hope it will solve your problem.
So if I use the node he client how is auth information being passed around ?
In the photo frame example it checks form data using the express body parser for a user and is authenticated function call.
But then it also calls api functions and makes requests outside the browser.
Just curious what the process is storing and where and how it’s being passed around.
Obviously the application tells Google what it is with some use of the client ids but is there a token the application has access to as well once OAuth is finished identifying the specific user account and where is that ? And how does the connecting browser keep this between server calls ? The response headers seem empty of anything of that nature. Thanks in advance.
I'm working on an implementation of the Facebook api and I'm to the point that i can fetch a users pages and would now like to display these to the user so they can select where to send the post. These page objects have an access token on them to verify requests with Facebook and intuition tells me you wouldn't want to send these through to the ui then back again. I could just make 2 calls when sending and receiving, filter the results to remove the access tokens, then when receiving a request make another call to the api and filter the page results by id.
I'm curious though if theres a way to get around making 2 api requests and reduce overall requests to the api and keep the usage down.
You could just store the page tokens in the session, when you get the list of pages - then you don’t need to make a second API request after the user made their choice.
(Session data is tied to a specific client, and never leaves the server. Only thge session ID is passed between client and server.)
I am resolving user data using firebase for auth like so:
from firebase_admin import auth
decoded_token = auth.verify_id_token(client_id_token)
I am initializing my firebase creds with firebase_admin.initialize_app(cred)
Here cliend_id_token is a token that the client sends. However, this takes around 1 second to perform, which seems way too long. One possibility is to use a caching layer above this (lru cache, memcache) but it still seems that it should not fundamentally take so long. Looking at the the signature of verify_id_token there does not seem to be anything that stands out as something that I can pass in:
def verify_id_token(id_token, app=None):
Any thoughts on how to diagnose (or if I am missing something)?
The problem is because that function does an http request in order to have the key to decode the jwt. In addition, because it returns info such as the email of the user, while the jwt contains only the uid as sub field of the decoded jwt, I think that it does another http request under the hood to get the user from the decoded uid.
You should implement your custom decode function, following the docs: https://firebase.google.com/docs/auth/admin/verify-id-tokens
I'm having the same issue. It's about 200ms for me (I'm using fastapi). #EuberDeveloper - glad to hear it's the same on node js - you saved me from testing it out.
I wanted to mention how I got my setup working faster in case anyone would benefit.
I've got Google API gateway with Firebase security defined in the swagger spec in front of a Cloud Run instance. API gateway validates the jwt (as per the swagger spec) and passes on the authorization header to the backend as a renamed header (from memory it's X-FORWARDED-AUTHORIZATION but best to double check). This is pretty fast.
Then in the backend you don't need to validate the id token since it'll already be validated by the time the request gets there. And if you send the UID along in the request to your backend as well as the idtoken in the authorization header, you can fetch users with the UID field you send. This removed that 200ms it was costing me to decode the id token.
Note - if you want to do things like check how old a refresh token is and revoke it for some reason then you'll still need to decode the id token.
We currently have sessions disabled.
Instead, each request is sent with an access_token so that at the end of the request, nothing persists to the next request.
ie. Request received --> Validate access_token and set associated user as "current user"
The first issue we came across was the ability to access this use throughout the application.
eg. We need current user id in the repository
Our solution was to use node.js' domain. This didn't work out so well because when concurrent requests happened from different users the domain would be overwritted -- it was shared.
What I need is:
A globally accessible (or by require) object that can contain a
couple parameters I assign to it.
This globally accessible object to be unique for each request so that any given request could retrieve the information pertaining to itself.
Any suggestions?
The simplest way is to just attach it to your request object (do it in some middleware if you're using express).
req.access_token = 'get_the_token_and_put_it_here';
Now it's accessible from everywhere you can access your request object.