Storing User information and keeping a user logged in


#1

As the title reads, this is a 2 part question.

Need some advice here. Hopefully someone has encountered this and has a good solution.

Upon first launch of our app, the user is prompted to register an account, login, or they can continue as a guest. There is only 1 section of our app that requires a user to be logged in to view.

The issue that I’m coming across is when a user logs in we need to store their profile information in case the customer wants to view/update it. I think this will be tied to the next question but what’s the best practice here?

Second issue is how to properly keep a users session going. Our API(Backendless) returns an access token that can be stored in the keychain for future use. How do I log the user back in on subsequent app launches and access their profile data?

Has anyone implemented something like this? I’m tagging @markpiller from the Backendless camp as well to see if he might have some insight on the best way to attack this.


#2

Good questions to ask.

You can continue to use the access token while it’s still valid and store it as a device variable if you want to hold it indefinitely. You can also store the login credentials as well so you can retrieve them when you’d like to use them in app perhaps to receive the refreshed token upon expiration.

Does this help give insight on the direction to go here?


#3

Thanks @wade. I’m definitely storing the access token in the keychain. What’s the best practice on storing user credentials? Do those also go into the keychain or device variable?

Maybe a deeper explanation would help as well. I’ll walk you through the flow. My app has 5 main tabs for navigation. The home page is the first tab and the third tab is the page that requires being logged in.

  1. The user opens the app and on first navigation to the third tab they login. Upon successful login they are pushed to a “logged in” page. There are page variables that are stored from the 200 status(users name and other info). Also, the user is prompted to save their credentials to skip future logins.
  2. User closes app and then returns to the app. I’m not sure at this point what I can do with the page variables that I captured from the successful login. When then user returns they should be logged in and the third tab would be pushed to their “logged in” page. Maybe I’m handling the flow wrong and that’s why I can’t get this work correctly.

Should I just store the user credentials and log them in every time they open the app? If so, what’s the best way to do that? Thanks Wade.


#4

Hey Matt, Thanks for the explanation here.

This is a spot where you could go a few ways. Some of this is contextual to the app so I’ll try my best to hit your context best here…

When it comes to credentials, Keychain on iOS will secure them internally. Android’s Device variables are secure natively… so using those respective to platform are the approaches when it comes to handing sensitive credential info within the app.

I think your login flow is currently fine and if you want to manage when the user is logged in, you could just as easily re-log them in each time and get a fresh token. People do this. It works fine for most cases and really is just refreshing the token more than it needs to be but it’s a very low overhead so unless there’s a bad reason from the particular app use point of view, you can do that.

The other thing you can do is that, since you have that access token stored from their last login, you could for example, make a API request to verify if the access token is still valid. If it’s valid, you know the login procedure isn’t necessary. So you could do this step and if it’s indeed expired, you know a new login is necessary for any subsequent requests to go through.

Again, it’s sort of contextual to the app and the underlying backend how you’d like to proceed but I think you can take either solution and call it done, especially in the apps adoption days. As it grows in users and API hits, this could be a spot for making efficiencies down the road to reduce the amount of login requests occurring.

Again, it’s a great question to ask.


#5

Thanks Wade, that helps a ton. I also found a few options within the Backendless documentation for the RestAPI that I can take advantage of. I wasn’t aware of a couple of calls to retrieve or update a users profile. I can store the user id and token for subsequent calls.

So one question though. If I’m storing the username and password in the Keychain, do I store them as one value for each? It’s a strange workflow to retrieve those values since you can only retrieve one value at a time then define what happens when the value is found. Do I retrieve each stored value and then set value on a specific field or is there something I’m missing? Does that make sense?

Edit: Also, I noticed something that I haven’t noticed before. Say the user taps the tab for a login page, then they enter their login info and tap login. Next they are successfully logged in and upon the 200 response they are pushed the “Account” page. This is where it gets interesting. If the user taps the tab for the same page they are on, they are taken back to the login page. They aren’t logged out and nothing programmatically happens except the user is forced back to the main page that started the push navigation. Maybe I’m handling the login scenario/workflow incorrectly?


#6

On the “do I store these in the keychain as 1 item or separate” question… I believe in this use case, you will store these as separate items and retrieve them 1 by 1. I’m thinking more generally on this so there may be a creative solution to this but if not, separate seems like the more straightforward approach.

On the last issue that comes from a potential unlikely user navigation possibility, I wonder if there’s a method to block that navigation off somehow? I’m not sure if a tab could be disabled so they couldn’t “go into the same tab they are on” or perhaps the navigation goes through some of/else logic so that if it’s unnecessary that they go back like this, it doesn’t trigger the unintended workflow?


#7

Thanks Wade,

I spoke to Mark Piller about a few things regarding how the API service is currently setup. I’ve been working on some changes to the service but not sure if my new backend workflow will change the front end flow. However, I’m going to try a few different ways of how the app is setup and how the flow of logging in is performed and handled. I’ll report back on it here in case it’s helpful for others.


#8

I love the collaboration going on. Thanks @markpiller for all that you do for our Dropsource community as well!