I'm learning the basics of iOS development, and I'd like to make a simple application that connects to a web service. I've got a lot of experience on the web application side, so I'm comfortable with what kinds of requests the app needs to send/receive etc. The part I'm not sure about is what the big picture architecture of a service-backed mobile application looks like.
When my application runs, I have one major requirement: the user must authenticate into the web service. The web service can send back a token and the app can use this for all subsequent requests. I want the user to be able to log in once, and for the app to stay logged in (ie the token remains valid for that device) indefinitely unless they log out.
Until the user logs in the application should really just be a login screen. If they log out, the same. Otherwise, they don't need to see the login screen at all.
So my question is, what is the right way to structure this?
In AppDelegate, do I want to make a LoginViewController and set it to the rootViewController? Then if the user is logged in, push to the main view for the rest of the app?
Or do I want to initialize the main part of the app (for instance, a UITabBarController with a few views in it), and check for a token, and then display a modal login screen if no token is available?
What I'm not clear on is what the rootViewController should be for an application like this, and how the app should keep track of whether the user is logged in, and determine what screen to show when the app is opened.
If anyone can give me a high level overview of how such an app should be structured, I'd really appreciate it.
Thanks!
There isn't really a right way to do this, either flow could be appropriate for an application. If I had some UI or data that would be displayed if a user is not logged in then I would use that as the initial rootViewController and use a modal login dialog to force the user to login. On the other hand, if I had nothing to display until a user has logged in then I would setup the login view controller to be the initial rootViewController if the user is not currently logged in.
For keeping track of the user being logged in you should leverage NSUserDefaults to persist the authentication token. Then in the application:didFinishLaunchingWithOptions: call to your app delegate look for this token in NSUserDefaults (and possibly validate it with the server) then set the rootViewController as appropriate.
Related
I'm working on two iOS applications that share the same keychain tokens which they receive when the user logs-in in either of the apps by entering his username and password in a web view. The tokens saved saved in the keychain, are time limited for a few hours/days - they are being refreshed when the user uses the app and makes request/enters items which are being opened in a browser.
Up until the release of iOS 11, the web view in the app was a SFSafariViewController instance and it was very convenient because it shared the cookies between the apps and once a user logged-in in a browser in one app, he would automatically be logged-in in the other app, thus achieving an SSO experience.
In iOS 11, the behavior of SFSafariViewController changed, and it no longer shares the cookies between different SFSafariViewController instances in my two apps. Instead, Apple wants us to use SFAuthenticationSession to achieve the same behavior.
In my app, I have a table of about 50 rows, almost all of them open a different URL in SFSafariViewController. So now, in iOS 11, I need to create a new instance of SFAuthenticationSession every time (the URL cannot be changed once the instance was created), and in order to actually show the web view, I need to invoke the start() method on this instance. However, this method can only be invoked once on the same instance (otherwise it will return 'false' and do nothing), and every time it is being invoked, it pops the notification that "myapp" wants to use "mydomain.com" to sign in.
So it means that my users see this alert message on every tap on a row in the table.
Is there a way to make my app show the consent alert message only once, e.g. on the first time or something? I want my users to have an SSO experience in my two apps, that's why I used SFSafariViewController in the first place, but I don't want them to see this annoying alert on every tap they make in the app.
There is currently no way of having the alert message only show once using SFAuthenticationSession, we are experiencing the same issue on our apps.
I along with many others have filed a bug regarding this to Apple, asking them to show it only once like you suggested. The end of this GitHub thread discusses the alert.
the reason I am asking this question is because I am not using firebase or parse to create accounts. I have used my own code to use CloudKit to login and so on. My question is, after the first time opening the app, and the user making an account, how can I make sure that the following time they open the app, it bypasses the login page? And then, if they logout, the next time they open the app, it takes them to the login page. How can this be done.
TL;DR how can I track whether or not a user has been logged in, and then open the app to a 2 possible scenes based on whether or not they are or are not logged in.
Firstly, you could keep the user sign in data (like a returned authkey, or a boolean flag) in the Defaults for the app.
Secondly, you could make a "Loading View" where you would check if that data is present.
Lastly, if the data isn't present move him to the login view, else to the main app.
I am currently developing an app which does have a user system. After user logins to the app, I will store user access token from the server and next time the app launches, the user will be auto logged in(or the login screen will be displayed if user is not logged, so the rootViewController will be set in applicaion didFinishLaunchingWithOptions).
So my question is what is the best practice for this? Currently what I have in mind is to set the root view controller to be some new controller(with in a spinner to indicate progress), and after the auto login(checking with server if the access token stored is still valid, if not valid, can be refreshed or not and stuff), I will manually set the rootViewController to be the correct one.
Someone also suggested me to hold the launch screen until the response from server is received.
thanks for your help.
Its may depends on the app security level. ie. Once the home page have no more secure details to display you don't have to hold at launch screen. but If you are developing a high secured app, Its must wait at launch screen until the responds is come from server for token check.
I have been struggling with this question and cannot seem to find a clean answer for. I am using social login in an app I am writing (my first). After the app launch, the user gets authenticated with his choice of a social network, in particular, Facebook. when a user suspends the IOS app for days, and returns to it, the app returns right where the user left off, away from the initial login mechanism and the login viewController. How and where do you attempt to verify if the user Facebook token changed (due to password change) or expired? from what I understand you have to make a social graph api request, but does that mean I have to implement this request in every viewController in my app? I am under the impression that when the app becomes active it will only load the viewController displayed before the suspension. Maybe I am wrong.
your input is greatly appreciated.
Regards
So I do have controller over what I present when an app becomes active. I can simply present in the window the login view controller. I can silently verify the credentials. if pass present the next view controller. if not present the login page for the user interaction.
cheers
Here's my scenario. As part of my app when someone is sent a message it sends an alert to the phone. If they click on the alert I want to open up the specific message they were alerted to. I have a view message controller that will show the specific message. Here are my questions:
What is the best way to handle a notification while the app is open? I get the alert in the appDelegate, should I show an alert box that's triggered from there and open the correct controller if they choose to view it? This seems like code that doesn't belong in the appDelegate, but I don't know how that would otherwise happen.
For the login, this is a very similar question. When they are logged in it logs them into the server, and they stay logged in for a period of time. When the app loads I want to fire off a check on the server to see if their login has timed out. If it has I want to push them to the login screen of the app. Would this also happen in the app delegate?
My third question is how to best handle getting the phone id. I have the method set up in my app delegate where I get the ID when they accept the push notifications. My plan is to check and see if they are logged in, and if they are check to see if I already have their id saved to the server. If not send it up to save. Is that the best way to do this?
Yes, you would want to show a notification (UIAlertView is perfect for this), so the app doesn't suddenly change views, or jump around when a notification comes in. You'll want the user to be in control of whether they want to view the content related to the notification, just like they can choose to ignore notifications from apps anyway.
Yes, or switch the view to whatever view controller handled the login (you could do this modally). Be sure to let the user know why they're seeing the login view: "Login is required to view [NOTIFICATION]" or something like that. But it depends on the rest of the flow of your app.*
Not entirely sure which ID you're referring to? You might want to store a unique token in the app which you communicate to your server. This token is generated on the first login, for example which enables you to match up the user's login with the token. A UUID might work, or you can roll your own.
*A note on your auto-logout, why do you have this? Most apps stay logged in at all times, and let's the user control when they want to logout (Facebook, Twitter, Instagram, etc. - unless it's a banking app or PayPal). Alternatively, you can let the user add a custom four-digit login code like the Dropbox app for example.