Storing additional data in session
Hi everyone 😉 I'm exploring a possibility to develop my new project in WASP which looks really awesome! However, I've got a question related to
auth and was not able to find the answer... In my case user can belong to multiple organisations and switch between them once logged in. I'd like to store the current org ID in session is there any way to do it? I've been using blitz in my previous projects and it has ctx.session.$setPublicData() which is neat (https://blitzjs.com/docs/session-management#customize-session-public-data-in-typescript). Is there any alternative to this in WASP land? Thanks in advance!12 Replies
Hi @aslauris. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hello! Wasp's auth uses sessions to keep track of the logged-in user. The session is stored in
localStorage on the client and in the database on the server source (https://wasp-lang.dev/docs/auth/overview#sessions).
However, as of the current state of Wasp, there isn't a direct equivalent to Blitz's ctx.session.$setPublicData().
That said, Wasp does allow you to customize the signup process by defining extra fields. This could potentially be used to store additional information about the user, such as the current organization ID source (https://wasp-lang.dev/docs/auth/overview#1-defining-extra-fields).
Additionally, there is an open issue on GitHub discussing the possibility of providing a managed client storage solution, which could potentially be used to store additional user-specific data source (https://github.com/wasp-lang/wasp/issues/1082).
For more complex scenarios, you might consider setting up a custom Wasp API endpoint that can query the user info source (https://discord.com/channels/686873244791210014/1214656571787710474).
Please note that these are potential solutions and might require additional customization to fit your specific use case. It's always a good idea to follow the ongoing discussions and updates in the Wasp community for the latest features and improvements.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @aslauris, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@sodic another one to pick up when you have the time
Hey @aslauris, Wasp doesn't support this out of the box.
But you can let me know how you'd want to use it (e.g., is it persistent in the database or just a property of a browser session that doesn't need to be stored anywhere)
And we can come up with a way to best implement it
Both for Wasp in the future and for you now 🙂
Hi @sodic thanks for getting back! To be honest, I've never checked how it's done under the hood (until now) as it comes with a convenient API and just works 🙂 Blitz provides the following APIs:
-
ctx.session.$setPublicData() or setPublicDataForUser() to set public session data in the server side
- it persists data in the DB sessions table as a json object and also sends back the updated public data in the response cookie as a base64 token which is persisted in both cookies and local storage
- public session data could be accessed via useSession() in the front-end and e.g. ctx.session.orgId in the back-end
I found it really helpful in some use cases (user roles, multiple orgs per user, etc.). Of course, it's not a show stopper for me as I can implement some alternative myself but it might be a nice addon to WASP. I hope you'll find this useful too. I'm new to WASP but so far so good, nice work guys! 😉This is great stuff, @aslauris!
Thanks for digging in and getting all the details.
Yes, we definitely have no such system. Also, yes, you can 100% do this yourself (let me know if you need any help), but it's pretty manual at this point.
I'll create a GitHub issue for exploring this system and link your message if that's OK with you 🙂
Sure thing @sodic !
Here's the issue, it even got a nice round number: https://github.com/wasp-lang/wasp/issues/2000
Sweet ❤️
Bumping this, would like to use session based auth for organization use case. So need to store organization ID as a persistent session. Any tips for doing that in my backend code?
So need to store organization ID as a persistent session.Session data is just another way of saying data that belongs to the user (there might be some niceties like automatic deletion of the user data, but still it's still user data). Since Wasp doesn't currently support storing extra data in session natively, I'd suggest implementing a new table or a field on
User where you keep the extra user data you need. You could keep it in some other store like Redis or in-memory, but you'll know the best choice for you e.g. some of them are less permanent storage solutions or some are faster than others.It's a little different.
I.e. the user has 3 organization memberships but is currently using organization A vs B
This is important because the user may have different permissions across the workspaces, and the API should be wise to which organization the user is acting on behalf of.
So yes it belongs to the user, but more so the session in the same way as saying "the user is logged in" i.e. "the user is authenticated to XYZ organizion currently"
If you disagree @miho would appreciate your thoughts
So yes it belongs to the user, but more so the session in the same way as saying "the user is logged in" i.e. "the user is authenticated to XYZ organizion currently"Yep yep, I agree with you, the keyword is currently that's why I said earlier:
there might be some niceties like automatic deletion of the user data, but still it's still user databecause session data is something that exists during the session and gets cleaned up later when the user logs out or the session expires. You can simulate by making sure that some info expires after some time e.g. with some timestamp. You could set some initial data in the
onAfterLogin hook so it's always updated/cleared on each login change. Then when user changes their org, update the data. Next login, they start with the initial data again.
Even better would be having an onLogout hook. We don't have onLogout hook which could be really useful here e.g. clear the user info that was set for the current user.
I'm just saying that you could get some sort of custom system in place that would help you to keep track of some current state which you could clear on next login. Kinda simulating session data. This is great food for thought for us, we are tracking it here: https://github.com/wasp-lang/wasp/issues/2000