Closed aranvir closed 5 months ago
Hey @aranvir. q.user
assumes the presence of an OIDC authenticated user (maybe our docs need improvement). You can see how it's scoped here. The example you linked uses a custom JWT auth.
I see, thank you for the clarification. Then I implemented this JWT approach with the wrong assumption. But I also guess it's then not even possible to use user
state reasonably without OIDC, right? Or rather - I assume that user state is then also shared across all users like app state.
Does it then even make sense to keep the JWT example, if it can't work?
But I also guess it's then not even possible to use user state reasonably without OIDC, right?
You would need to implement your own version of q.user
: A global dict keyed by JWT token usernames/subjects whatever. The implementation would be very similar to the one I linked above. Another option would add it natively to Wave somehow.
I assume that user state is then also shared across all users like app state.
Correct. Non-authenticated users have auth.subject set to anon
. Since all users have the same key so it basically equals to q.app in that case.
Does it then even make sense to keep the JWT example, if it can't work?
I would say it does. It only can't work with q.user
. The point of the example is to show that JWT is possible (login screen) if you put in the effort. In real-world apps, user-state is stored in an external DB anyway, not in-memory.
Thanks again for the feedback! That gives me some food for thought...
Also, since this is a very niche feature (most folks go with OIDC), it won't be prioritized, but I am fine with accepting a contribution as long as it doesn't make the code much more complex.
Feel free to ping me in case of any more questions! Covnerting this into a GH discussion.
Wave SDK Version, OS
Wave 1.0.0 (and v0.26.3) Windows 10 Python
Actual behavior
When using
q.app.user
to share state for a user session, this state is actually also shared across browser instances of the same computer. There might even be the case that it is shared across computers (see https://github.com/h2oai/wave-apps/pull/118#issuecomment-1910467589)Expected behavior
As described in https://wave.h2o.ai/docs/state, it is expected that the state is shared across tabs of a browser session (clients of the same user). Opening a different browser session (incognito mode, chrome instead of firefox, different computer) should give each user "fresh state".
Steps To Reproduce
I provided sample code below which lets you set a user name that is stored in
q.user.name
. I tested this with Firefox, Firefox Incognito and Chrome. In my home network, I could not figure out how to servewaved
on 0.0.0.0 and running a proxy also didn't really work (probably my firewall, idk). I did test it with a browser running from WSLv2 on the same machine, accessing the app via the proxy, so that "should" be like a different computer since it's not originating from localhost. But I did not manage to test this with actually separate computers in the same network.However, as mentioned before, @HugoP reported that the user state was shared on different computers for the same app.
The example below is with
run_on
but I also tested it withhandle_on
for version 1.0.0 and version 0.26.3 just in case.