https://supertokens.com/ logo
Join Discord
Powered by
Circling back to this. I *tried* to update this re...
# share-your-work
i
Circling back to this. I tried to update this repo with an example of storing 
form
data in 
localStorage
while a user is making their way through a complex form. It's not robust but I think it at least covers some basics for anyone who's worried about it. (A solution like this is necessary to make sure that users with JS enabled do not lose their progress if they're redirected in order to re-authenticate after a complex form submission.)
The main files of interest for this are the 
form-test.tsx
Route and the 
useFormLocalStorage
hook.
r
If someone has enabled js, why not just make it use the normal way of doing session refreshing?
i
Two main reasons: 1) Less Importantly I'm going to need the same 
localStorage
logic for every other reason that the user refreshes the page or navigates back to it. So it's easier to just reuse that logic. Of course, someone could say, "It's pretty easy to do 
SuperTokensWebsite.init()
as an add-on regardless." So that leads to part 2. 2) More Importantly it's hard. 😅 Remix is much more powerful and also much more easy to work with when developers work with (not against) the framework. And that more or less necessitates creating an app that plays nicely with their 
Form
component (even if you aren't building a site that can accommodate non-JS users). There are a ton of advantages that come from using their 
Form
component. So it's by no means disadvantageous, but it's still a constraint in development. Using their 
Form
component necessitates properly mapping auth requests during form submissions. But it also requires cleverly handling redirect scenarios when users are not authenticated, as you saw in the 
server.js
file. On https://github.com/ITenthusiasm/remix-supertokens/issues/1, you mentioned that: > Normally, if you used 
verifySession
middleware, it would send a 401 to the frontend and the 
supertokens-website
repo would do an automatic refresh. But in order for our application to work for both JS and non-JS users, the server has to swallow that error and take care of the redirects itself. So no 
401
response ever gets sent. If 
supertokens-website
relies on the 
401
error, then we're in trouble because the server is no longer sending `401`s with the current implementation. We could update the server to send the `401`s, but that makes it impossible for non-JS users to easily re-authenticate. So what we end up with is a situation where -- in order for 
supertokens-website
to be reliable -- the server would need to know whether the user is a JS user or a non-JS user. And though doable, that task seems more complex.
--- When I was first looking into this, I learned that we could try to use Cookies to get the job done: https://stackoverflow.com/a/121259/17777687. But that gets a little involved... You would need a 
<noscript>
tag that sets the Cookie. (Let's call the Cookie 
javascript-unavailable
.) ... Then the server would need to check the cookie to determine whether to swallow the error and handle the redirect itself (for non-JS users) or to let the error pass through so that 
supertokens-website
can handle it (for JS users). The absence of a 
js-unavailable
Cookie would indicate that we should let the error pass through, because they are supposedly a JS user. This approach already makes the logic in 
server.js
more involved than a developer may like. And this is why I ultimately leaned in favor of just relying on 
localStorage
. Additionally, we still need the 
localStorage
logic regardless. So that has to be built out. And then we'd have to load up 
supertokens-website
alongside it so we can make refreshing easier in that one special use case with forms. (Admittedly, at least that part is not too bad.) But even then... not every use case can be handled, as the person in that StackOverflow answer mentioned. There are more odd scenarios too... Two Examples: 1) Ideally, if a user suddenly enables (or gains / regains access to) JavaScript, then we'd want to give them a better refreshing experience. This means we need some kind of JS 
effect
that clears the Cookie on page load. But this can get dicey in some cases... 2) If an authenticated user who already had JavaScript enabled suddenly lost (or disabled) the ability to use it, then they could make a form request to the server without the important 
js-unavailable
Cookie. At that point, they'd get a 401 but wouldn't be able to do anything with it, and the app would appear to be broken in an unfamiliar way.
--- Sorry I know that's a lot of text. That's basically everything that my mind has been running through when trying to approach this problem. But it seems that if I try to go the Cookie + 
supertokens-website
approach, it becomes more complex than it's worth. And there are still some edge cases that can cause problems. I don't run into any of those problems if I just keep things consistent by relying on 
localStorage
and letting the server handle all the redirecting. Does that make sense? If you have any other ideas for approaching this problem, they'd be appreciated! I am more or less happy with using 
localStorage
though, as I don't think it's a bad user experience. And if desired, it should be pretty easy to include a "Re-authenticated" toast / popup notification to explain why the form refreshed (while retaining their progress) instead of doing a normal submit. But even that's easier to do than the Cookie + 
supertokens-website
thing.
Just following up. Any thoughts on this? (Or maybe you haven't had a chance to read it? I know it's a lot. 😅)
r
> But in order for our application to work for both JS and non-JS users, the server has to swallow that error and take care of the redirects itself. So no 401 response ever gets sent. Hmm.. That makes sense. > So what we end up with is a situation where -- in order for supertokens-website to be reliable -- the server would need to know whether the user is a JS user or a non-JS user. And though doable, that task seems more complex Hmm. So requests in which the JS is enabled will have a custom header -> 
rid: ...
. So maybe the server can see if that is there, and if it is, then it can send back a 401? > I am more or less happy with using localStorage though, as I don't think it's a bad user experience. I agree. So perhaps it's OK to just keep it as it is and do redirection either way.
i
Helpful! Thank you!
2 Views
PreviousNext
Powered by