Correctly Handle A Returning User

[williamflaherty]

We need to make sure that when a person has registered previously that when they open the app they don't return to the login/setup profile workflow.

I'm thinking there should be 2 checks here: Storing their uuid(maybe that should be a generated db number instead of their instagram username?) in NSUserDefaults and then when the app is open we make a call to the db to see if this user exists.

If they do get to the new user login screen then when they try to signup we recognize them already being a user and skip straight to the matches screen after they type in username/pw. (This actually makes me realize we might need to change the wording on the starting page to "signup or login" so there isn't confusion.

[nziebart]

I think a common way to do it is this:

• The server returns a token from the login and create account endpoints. This token expires after x period of time.
• The app stores this token, and sends it with all API calls for authentication purposes.
• If the token expires, the app must request a new token by calling the login endpoint again.

Also:

• To avoid the user having to retype their password every time the token expires, the app should store the password securely. This way, it can automatically renew the token when necessary.
• The server should look at the token on every request to ensure the following: a) The token corresponds to a valid user b) The token is not expired c) The user corresponding to the token has permission to perform the API action. For example, we don't want user A changing user B's settings, or looking up their private profile information.

On Sun, Feb 22, 2015 at 10:21 AM, William Flaherty <notifications@github.com

wrote:

We need to make sure that when a person has registered previously that when they open the app they don't return to the login/setup profile workflow.

I'm thinking there should be 2 checks here: Storing their uuid(maybe that should be a generated db number instead of their instagram username?) in NSUserDefaults and then when the app is open we make a call to the db to see if this user exists.

If they do get to the new user login screen then when they try to signup we recognize them already being a user and skip straight to the matches screen after they type in username/pw. (This actually makes me realize we might need to change the wording on the starting page to "signup or login" so there isn't confusion.

— Reply to this email directly or view it on GitHub https://github.com/williamflaherty/Pearing-App/issues/12.

[williamflaherty]

@nziebart Right now we do all of what you mentioned, I believe, minus checking permissions for the API call being made (part c). (@Mimimiel could you verify this?) I think the only actual problem we might have is that the token expires after 1 day. But when it does we can re-authenticate immediately. Looking at the authenitcate_user_with_instagram funciton though it seems like it just checks to see if the user exists for a given token, which they always will. Which I guess is fine...? Seems sketchy. (looking again it looks like there is no guarantee that an access token from IG is valid, it can expire at any time, so we may need to put something in place to prepare for that scenario.)

Right now though I don't believe I've got all this setup correctly in the app.

The initial token we get uses the implicit flow documented here: Instagram Auth meaning the initial access token is received by us and sent to the API for them to store. I don't think I use the login methods in the API right now at all, they're just used by other API calls for auth. (This could cause a problem for preparing for the scenario I mentioned up there, I think, random expiration of token.)

I'll step through the current flow again and refresh my memory on it tonight and hopefully we can have this all figured out in the next couple of days.

[Mimimiel]

Willie/Nathan, I'd want to run through it to be 100% sure, but yes, all of that is done. The only one is maybe c, but I'm 50/50 if I checked that. I remember thinking that when writing the code, but I don't remember writing the actual code.

Willie, as for your comment, "Looking at the authenitcate_user_with_instagram funciton though it seems like it just checks to see if the user exists for a given token, which they always will." It won't just work if it has a token, it will actually check for validity (expiration/IGauth/etc).

On Mon, Feb 23, 2015 at 12:43 PM, William Flaherty <notifications@github.com

wrote:

@nziebart https://github.com/nziebart Right now we do all of what you mentioned, I believe, minus checking permissions for the API call being made (part c). (@Mimimiel https://github.com/Mimimiel could you verify this?) I think the only actual problem we might have is that the token expires after 1 day. But when it does we can re-authenticate immediately. Looking at the authenitcate_user_with_instagram funciton though it seems like it just checks to see if the user exists for a given token, which they always will. Which I guess is fine...? Seems sketchy. (looking again it looks like there is no guarantee that an access token from IG is valid, it can expire at any time, so we may need to put something in place to prepare for that scenario.)

Right now though I don't believe I've got all this setup correctly in the app.

The initial token we get uses the implicit flow documented here: Instagram Auth https://instagram.com/developer/authentication/ meaning the initial access token is received by us and sent to the API for them to store. I don't think I use the login methods in the API right now at all, they're just used by other API calls for auth. (This could cause a problem for preparing for the scenario I mentioned up there, I think, random expiration of token.)

I'll step through the current flow again and refresh my memory on it tonight and hopefully we can have this all figured out in the next couple of days.

— Reply to this email directly or view it on GitHub https://github.com/williamflaherty/Pearing-App/issues/12#issuecomment-75604249 .

[nziebart]

Oh I see. We don't have our own password, we just use instagram to authenticate.

I'm not sure how that is typically handled. I think most websites still make you create a password, but they allow you to authenticate using either your password OR a third party.

Anyway, it seems like we are doing this:

• App passes IG token to register endpoint
• Server stores this token in the database
• App passes the IG token on all subsequent calls.
• Server re-validates the token with IG every 24 hours, and uses the token to authenticate the user.

What I was suggesting is that we do this:

• App passes IG token (or a password, but currently we don't have a password) to login and register endpoints
• Server authenticates the user (via IG), then generates its own token and stores that in the database
• App passes the server-generated token on all subsequent calls
• Server uses this token to authenticate the user. The token should expire after xx period of time, at which point the app must log in again.

The reason is that this allows us to not be tied to instagram for authentication. Let's discuss options if there is a better way to go about this.

[Mimimiel]

Willie:

Re-reading the original scenario, we definitely need to implement Pearing users in the database. This will allow you to have your uuid and better handling of the IG name changed regardless of our authentication scheme. We technically have independent uuid's now, but I would want to put more restrictions in place. It would also mean switching the meaning of username and handle in the person table.

Nathan:

Apps that let you auth with an external service (such as FB) do not usually ask a separate password from you. Forcing users to enter a Pearing password doesn't seem right when we are so tightly coupled to Instagram regardless of our authentication scheme. That being said, if we go with your suggestion, we need to move all of the IG auth to the server. Right now, the app takes care of the part that actually gets the token from IG. We did the auth that way because it was simpler at the time, and that also ties into why Willie calls the API's authenticate with Instagram "sketchy"...even though that is an established way of doing it.

I think we need to choose an authentication scheme not because of whether or not it is tied to Instagram (because everything in Pearing is tied to Instagram from photos to the eventual matching algorithm) but on what scheme is going to handle users changing their IG username most gracefully. Willie and I briefly discussed the implications of 1) someone changing their username and 2) someone new coming in with an IG username that person 1 gave up but that we don't know about yet. It's going to be complicated either way, and really just seemed like we need to look at IG's documentation more closely.

On Feb 23, 2015, at 2:04 PM, nziebart notifications@github.com wrote:

Oh I see. We don't have our own password, we just use instagram to authenticate.

I'm not sure how that is typically handled. I think most websites still make you create a password, but they allow you to authenticate using either your password OR a third party.

Anyway, it seems like we are doing this:

App passes IG token to register endpoint Server stores this token in the database App passes the IG token on all subsequent calls. Server re-validates the token with IG every 24 hours, and uses the token to authenticate the user. What I was suggesting is that we do this:

App passes IG token (or a password, but currently we don't have a password) to login and register endpoints Server authenticates the user (via IG), then generates its own token and stores that in the database App passes the server-generated token on all subsequent calls Server uses this token to authenticate the user. The token should expire after xx period of time, at which point the app must log in again. The reason is that this allows us to not be tied to instagram for authentication. Let's discuss options if there is a better way to go about this.

\ Reply to this email directly or view it on GitHub.

[nziebart]

Yeah I can see why we would want to avoid making users come up with a password. It's extra work and we will only be logging in via IG for now anyway.

So I guess back to the original point of this issue, we can check if the user exists by whether we have a valid token for them.

The auth thing was kind of a side issue so I'm going to move it to my other auth issue.