Oidc-client-js: How to change from sessionStorage to localStorage on compiled version (dist)

Created on 23 Oct 2016  路  11Comments  路  Source: IdentityModel/oidc-client-js

Basically what the title says: how can I change from sessionStorage to localStorage on the compiled version? Because I followed and tried with userStore: new WebStorageStateStore({ store: window.localStorage }) as explained in the wiki but thats obviously for the ES6 version and doesn't work on the compiled version I need to use (there's no WebStorageStateStore).
Or perhaps I'm just overseeing something.

question

Most helpful comment

I made this work.
I had to add the options configuration in every constructor for the different callbacks used on the redirect pages.
So, for example, in the signinRedirectCallback I wrote it like this:

new Oidc.UserManager({ userStore: new Oidc.WebStorageStateStore({ store: window.localStorage }) }).signinRedirectCallback().then(function () {
    window.location.replace("./");
});

And now this works without problem.

One question left is: why using sessionStorage by default instead of localStorage? I found it more useful the later because it keeps the data in between tabs and windows...

All 11 comments

Have you tried using the following: userStore: new Oidc.WebStorageStateStore({ store: window.localStorage }). If you are using the files from the dist folder (UMD/AMD way), this is the way to go

I just tried and it doesn't even pick up the current user; as if not logged in. But the IdentityServer shows me as logged in. After I commented out the line, it picked up the user again as logged in.

I made this work.
I had to add the options configuration in every constructor for the different callbacks used on the redirect pages.
So, for example, in the signinRedirectCallback I wrote it like this:

new Oidc.UserManager({ userStore: new Oidc.WebStorageStateStore({ store: window.localStorage }) }).signinRedirectCallback().then(function () {
    window.location.replace("./");
});

And now this works without problem.

One question left is: why using sessionStorage by default instead of localStorage? I found it more useful the later because it keeps the data in between tabs and windows...

I think this is because sessionStorage is persistant as long as the browser window exists. Once you close it, this is cleared. In most cases this is the life time of your user sesssion. In most cases you want the user to relogin after he has closed the browser.

Yeah, what I think is odd is that lots of users might want to open a link on another tab or just another window and it looks kind of nasty that he/she has to login again just because of that. Also, it renders useless the "Remember me" option as it will never "remember" you...

Anyway, that's just my point of view as another use case for devs to take into consideration :)

All set on this issue?

Yeah, I left it configured as I explained above. Only doubt would be for you to confirm if everything is correct (like having to configure the option in every redirect page callback or if I'm overseeing something). Other than that I'm done. Thanks.

Yes, if you're changing the storage config then on the callback page you'd need to make the same config change.

Yeah I agree that it's weird that localStorage isn't default. Multi-tab usage is super common nowadays.

I avoided it because it stored PII to disk. I had customers who could not allow that, so I made session storage the default. Also, when you use a shared store, you then run into problems where multiple tabs might think they need to renew the token, so they're all competing to update the same thing. I didn't try to solve that, as it felt like it would be complicated.

Ok it's fine not being default, but I really think it should be a well supported config option. The current default behaviour I feel like is very surprising for new users of the library.

you then run into problems where multiple tabs might think they need to renew the token, so they're all competing to update the same thing

Yeah I don't know what's the cleanest way to do this, but I think figuring this out for the user should be one of the central things that this module does.

Was this page helpful?
0 / 5 - 0 ratings