Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to "load" a client instance from persisted state #8

Open
dan-f opened this issue Jun 6, 2017 · 11 comments
Open

Ability to "load" a client instance from persisted state #8

dan-f opened this issue Jun 6, 2017 · 11 comments
Assignees

Comments

@dan-f
Copy link

dan-f commented Jun 6, 2017

There should be a way to instantiate a client for a particular identity provider from the cache. This is useful because it prevents extra network requests to the identity provider when it's already saved ID/access tokens.

@dmitrizagidulin
Copy link
Contributor

Thanks. Will implement this next.

@dmitrizagidulin dmitrizagidulin self-assigned this Jun 6, 2017
@dmitrizagidulin
Copy link
Contributor

Quick question - would you like this method to register a client if no cached copy exists? Or just resolve to null if no stored client is found?

@dan-f
Copy link
Author

dan-f commented Jun 6, 2017

I'd rather there not be side effects. Since this client is designed to manage one session at a time I'm looking for something like:

const oidcClient = new Client('https://example.com', options) // loads any ID/Access tokens from storage
oidcClient.currentUser() // null if no stored user, webId otherwise

@dmitrizagidulin
Copy link
Contributor

No prob.

So this sounds like this is orthogonal to the rp client? As in, instantiating the client will load the last webId + tokens that were stored for that provider, but doesn't concern itself with the rp client (until it's needed by login())?

@dan-f
Copy link
Author

dan-f commented Jun 6, 2017

I was using the term client to refer to the interface this library exposes. I'm considering the rp client lib an implementation detail in that context.

@dmitrizagidulin
Copy link
Contributor

Got it. Couple more questions. One, would it be ok if the loading of user was performed by a factory method rather than constructor? Something like:

const oidcClient = Client.for('https://example.com', options) // loads any ID/Access tokens from storage
oidcClient.currentUser() // null if no stored user, webId otherwise

Two, just to double check - should calling oidcClient.logout() clear the stored webId & tokens for that provider? (So that the next time currentUser() is called, it would return null).

@dan-f
Copy link
Author

dan-f commented Jun 6, 2017

One, would it be ok if the loading of user was performed by a factory method rather than constructor?

Yeah totally.

Two, just to double check - should calling oidcClient.logout() clear the stored webId & tokens for that provider? (So that the next time currentUser() is called, it would return null).

Yep

@dmitrizagidulin
Copy link
Contributor

Would it also make sense to store the last selected provider uri (in local storage)? So that the app doesn't have to remember that https://example.com was it?

This would give something like:

const oidcClient = Client.for(options)
// ^ loads the last selected provider, https://example.com if available, and loads the webId + tokens for it

And maybe make providerUri as one of the options?

@dan-f
Copy link
Author

dan-f commented Jun 6, 2017

At the very least, I'd like to see the concept of "current user" for a developer-specified IDP URL. Currently it relies on the current window URL - https://github.com/solid/solid-auth-oidc/blob/master/src/index.js#L83

It'd also be really nice to index the last used IDP by app URL. That way you can pick up the last used user session for the current app.

@dan-f
Copy link
Author

dan-f commented Jun 6, 2017

I think we're saying the same thing

@dmitrizagidulin
Copy link
Contributor

Ok, cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants