Oidc-client-js: [Question]: How to access the session state on token callback?

[maxmantz]

When I call:

userManager.siginRedirect({ some: 'data });

How can I access this value after the redirect? I guess it's in the user object's session_state passed into the callback but I don't know how to decode it.

[brockallen]

userManager.signinRedirectCallback().then(function(user){
    var data = user.state.some;
});

[brockallen]

BTW, the state is not persisted with the rest of the user, so the resolve callback is the only place you will be able to capture that state. The rest of the user is persisted (profile, id_token, access_token, etc) and loadable via getUser().then...

[maxmantz]

Sorry to bother you again :-) Tried this:

userManager.signinRedirectCallback().then((user) => {
  console.log(user.state); // undefined
});

Everything else works fine. Am I missing something?

[brockallen]

What does the URL & hash look like? Before you leave your app to signin, do you see an entry created in localStorage (the state should be in there)? On the callback page, do you see that entry again?

Also, you can enable logging:

Oidc.Log.logger = console;
Oidc.Log.level = Oidc.Log.INFO;

and perhaps logging will inform us of something (tho, maybe not).

Finally, look at or run the sample in ~/sample to see if that's working.

[maxmantz]

When I hit the debugger during the then() of signinRedirectCallback() the session storage contains the user data just as when the user is logged in. There is nothing in local storage or anywhere else.

Wasn't able to get logging to work with the current module settings. I have to look into that. In order to get the samples to work I would have to setup a new identity server instance & webserver. That's a bit too much right now :) Will edit this when I have the time.

[brockallen]

The sample is self-contained (I built a lightweight fake OIDC server in node). Just run npm start and browse to http://localhost:5000

Also, look in localStorage not sessionStorage -- that's where the state is kept for signing in/out.

[maxmantz]

localStorage is empty during the callback.

[brockallen]

Check right before the call to signinRedirectCallback. If it's empty before the call, then none of it will work. Inside the call to signinRedirectCallback the storage is removed/cleaned up.

[maxmantz]

Got it. localStorage contains this:

oidc.975ff2a0f4be4e1e9b2c18304bd5d3c0: {
 "id": "975ff2a0f4be4e1e9b2c18304bd5d3c0", 
 "created": 1463656251,   
 "nonce":"757ff5a7668b4b3fa405d9257d2a7fec", 
 "authority":"https://localhost:4999/auth", 
 "client_id":"myclient" 
}

[brockallen]

Looks like state is not making it in there.... maybe a bug. I just reworked this recently.

[brockallen]

Yea, I'm looking at the sample and it seems to be working properly. Can you try the sample?

Here's what's in the state in the sample:

{
"id":"194df0a0c2364d1fb39717c4ce791a2a",
"data":"some data",
"created":1463657199,
"nonce":"d231ef0916bd45a9be76331eaeab8f5c",
"authority":"http://localhost:5000/oidc",
"client_id":"js.tokenmanager"
}

And here's the code from the sample passing the data:

function startSigninMainWindow() {
    mgr.signinRedirect({data:'some data'}).then(function() {
        log("signinRedirect done");
    }).catch(function(err) {
        log(err);
    });
}

[maxmantz]

Sample works fine for me too. Had to fix them because of the new build in my fork. Pushed a correction to the PR. I think I've found the error:

Only the data property of the object passed to signinRedirect() gets deserialized in the callback. So the correct usage should be:

userManager.signinRedirect({ data: { some: 'data'}});

Thanks a lot for your help!

[brockallen]

Oh yea, duh -- i totally missed that in your first post. Sorry.

[maxmantz]

No worries - I've found another quirk: seems like the user object passed into the callback has all its properties inside t. The structure of the user object looks like this:

{
  t: {
    access_token: "xyt",
    profile: {...},
    // ... 
  } 
} 

Don't know if that's something I've introduced though...

[brockallen]

Yea, that looks new.

[maxmantz]

It was my fault, just a weird debugging issue...