While adding user to sessions during login , I wan...
# support-questions
r
While adding user to sessions during login , I want to pass the role manually through the body of request. How can I get hold of the value in the create-session function 🤔
r
While adding user to sessions during login , I want to pass the role manually through the body of request. How can I get hold of the value in the create-session function 🤔
You can do this via the context feature we have
Which recipe are you using?
r
third party email password
Is there any speicif way to pass the role for the xcontext
See this ^^
You can pass the role as any key value you like in the context. You can even pass the full request object if you like
r
Oh . sounds like what I needed.
Sorry for disturbing again, but am not able to get hold of the body of my request. 😿 I just want body content of api_options.request
r
You should be able to get the body object for your framework by doing api_options.request.original
Or the request object itself also has functions to read the json body.
r
Thanks , found a way to solve the query. 😅
r
how did you solve it
? just curious..
r
used async , was getting an object reference everytime.
Copy code
async api_options.request.json()
did it
r
you do you mean await?
r
ah yes , sorry
r
@User let's talk here
What get's printed when you do
print(user_context)
?
r
empty object {}
r
hmm. interesting
might be a bug in the SDK
r
but there's something else too, during sign in , if I do the same exact thing, the context gets defined, so it's explicity for the sign up part
r
I see.
Thanks for the info
ok found the bug in the SDK. Will release a new version tomorrow.
r
Thanks, would update the package then...
Btw wanted to implement redis caching to store session data, so adding the redis SET method in the sign up overriding function should do my work. Isnt it?
r
You should do that in the create_new_session function - since that's called during sign in too.
Unless you only want to do this for sign_up
r
Ah got it, and would get the session details from the cache layers during verification.. thanks 👍
r
Yea. Makes sense. If you are OK with those info being accessible by the frontend, you can save it in access toke payload itslef.
this way, you won't need to use a cache. Since the access token would have the info and no db lookup would be required.
r
Actually was planning to remove the usage of postgres for storing the session_details and put all of that on redis , for faster transactions.
r
Well, my point is that you can store that info in the access token itself. And that way you won't need extra db / cache to get it
but if that doesn't work for you, then you can always optimise it via a caching layer - as you suggested.
r
Do you have any example where supertokens was used as a auth microservice ? Needed some reference for creating additionl api's
r
Im not sure what you mean. Can you elaborate?
r
I am exploring microservices and its different design patterns. In that, one of my microservice stands of to be Auth, which I wanted Supertokens to handle completely. There would be different api's which I would need to setup myself to handle sessions example In that, of session verification I would have a middleware , verifySession, which wont be present in the Other Microservices.
So, do you have as a example something where a microservice was created for a similar purpose
r
Uhmm. Not an example.
Would the other micro service auth be called from the frontend or backend?
r
wdym by "other microservice auth" .
r
> "which wont be present in the Other Microservices." Your words. hehe
oh i mean
those APIs in the other microservices would need to have some authentication right? Like session veirifcation or something
Who will call those APIs?
The frontend or the backemd?
r
backend
r
right. So what you are asking for is machine to machine auth. We have limited support for that atm
r
The auth endpoints wont be exposed directly to the internet.
r
But, you can use our JWT recipe for it
to create JWTs and then use those to query those auth services
Unfortunately, we don't have an example of this
r
hmmm, ig would need to change the flow of auth and make calls from frontend too..
Thanks, would think a bit more on my flow pattern 😄
r
> hmmm, ig would need to change the flow of auth and make calls from frontend too.. Well. You can continue to use sessions for calls from the frontend (that's the recommended way) For backend to backend, you can use JWTs, or have your own API keys, or put all the services in one private VPC.. or use another lib / solution for this.
r
Has the update rolled out?
r
yes. 0.6.0 version
if the error persists, lmk please.
Are you using fastapi?
r
Thanks, would check it out..
No, flask
r
ok. So no breaking change for you
r
Thanks , it is working as expected. Also is there a wayto add columns to the databse and fill them dusing sign up through form _fields
r
You will need to add these columns to your own db
We are working on a user metadata feature which will allow you to save JSON in the db against a user, but until then, you will have to do this yourslef in your own db
r
So the changes that would be required are: - add column to db - add the field in the form field during supertokens init
r
Yes.