Login Resume

[patrickml]

Is there any way to resume a login with this package? I know you just got start, i'm just curious is there is something undocumented.

[viestat]

I don't understand what are you referring with 'resume login', could you please elaborate on this so I can help you?

[patrickml]

Absolutely, is there currently a way with this package to resume a users
session without needing them to re-click the login button.
On Tue, Aug 23, 2016 at 10:59 PM Andrés C. Viesca Ruiz <
notifications@github.com> wrote:

I don't understand what are you referring with 'resume login', could you
please elaborate on this so I can help you?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHOuuTdT1PDwhbWBWZfmf9on6Ms2Zxouks5qi7N4gaJpZM4JpNdm
.

[viestat]

You can call the method loggedIn before calling setClientID:setRedirectURL:setRequestedScopes:callback but it will have a funky behaviour right now. I am working on updating this module to work with the beta 21, I will try to make this clearer on the next version.

[patrickml]

oh awesome -- thanks for making this package btw. I can't wait to see the beta 21 version!

[digitaldavenyc]

@viestat Is the funky behavior loggedIn not persisting if the app has been closed?

[patrickml]

correct, the login screen still shows. I really don't have a way to check if the user is logged in. So they have to click the login button everytime, they don't always have to re-render the credentials, but they do have to hit the button again.

[digitaldavenyc]

Is there anyway to cache login credentials in AsyncStorage or in Keychain?

[digitaldavenyc]

I think this is sort of a big issue because new app versions will likely kill the cache in WebKit (other factors could clear that as well) which will also require re-authenticate.

@patrickml What are the blockers preventing authentication to be persistent?

[patrickml]

@digitaldavenyc I'm not completely sure. For all i know it is persisting, but I know there isn't a way to know if the user was logged back in, i.e. Spotify.on('resume', () => {}) or something like that. Therefore you can't update your UI or have your UI wait to know if the user is logging in / being logged in / or has logged in.

[digitaldavenyc]

@patrickml logging back on isn't the issue as I see it. The user shouldn't have to log back on at all. There should be a cache of some sorts that stores data outside of the app, I'm thinking the Keychain is the most appropriate place to do this.

Do you know what type of authentication the library is using?

[patrickml]

@digitaldavenyc i agree, and im am not too sure as to the answer of your question. The app I made with this was for a 1 time event, so it diving in deeper wasn't needed. @viestat do you have any insight?

[viestat]

@patrickml and @digitaldavenyc , the auth process is OAuth. The way it is implemented right now requires the SPTAudioStreamingController to log in every time the app restarts. As I mentioned before I am working on an update to work with the SDK beta 21. A lot has changed and unfortunately I have had little time to finish it (hopefully soon! ).
I am thinking on a better approach for the login process so your input is super valuable. I agree with you, the user should have to login just once.
Sorry for the inconvenience...

[digitaldavenyc]

@viestat Thank you, really appreciate you putting time into this library, it's been incredibly helpful. Can't wait for the update. If I can be of any assistance I'd be happy to help.

Regarding the auth, Spotify has a few types of authentication and I was curious which type was in place:

• Authorization Code Flow
• Client Credentials Flow
• Implicit Grant Flow

Authorization Code Flow is designed for users to only need to authenticate once, which is why I was asking.

[moooji]

True, Authorization Clode Flow is probably the right choice here. It requires an oauth 2.0 back-end service though (for token refresh etc).

For example:
https://github.com/ciaranj/node-oauth

From the Spotify docs:
"This method is suitable for long-running applications which the user logs into once. It provides an access token that can be refreshed. Since the token exchange involves sending your secret key, this should happen on a secure location, like a backend service, not from a client like a browser or mobile apps."

[digitaldavenyc]

@moooji That's a good point about requiring a backend API for Authorization Code Flow since your secret key is required. It's possible some developers may not want to build an API to use the library. However, I think it should be an option to go one way other the other because it's a feature of Spotify's auth and apps (like ours) need an auth once solution.

Perhaps there should be two methods for auth? Simple and Code Flow?