I'm trying to make a login system for my cocoa app. How would I do this? I know it involves SQL, but I know nothing of SQL. I want the user to register or login. It would be easier if apple had a source code for this kind of thing, but I don't think they do.
Best Regards,
Kevin
Implement the login system on the server. Then all you have to worry about in your app is:
send them to your website via URL to
sign up
query for a name and password
if name and/or password is incorrect more than three times, go to 1
user is logged in. Do something.
You can also use the keychain on the iPhone to securely store and retrieve passwords. Here's excellent code from Sci-Fi Hi-Fi. You prompt for a password, store it securely in the keychain for later comparison. Pretty simple. Documentation on the site.
Related
Specifically this is for iOS but this could and WILL be relevant to an Android app as well.
I have an app in production use with a login portion that only loads if the user isn't auth'd. Now, I was wondering if I can have have 2 layers of this.
I'm currently checking if the currentUser is nil/null. If not, then I proceed. If so, I take the user to a login view.
I want to essentially have the user login 2 times if 2 layers are both signed out. But in this form:
UserA -> UserA-1
So if user isn't logged into UserA then they can't be logged into UserA-1, if that makes sense.
I'm not sure if Firebase has something already made to handle this or if I have to make my own. If the latter, i'm curious as to what approaches you guys have taken.
It's only possible to have a single user signed in at one time for one app instance. Signing in a second user will implicitly sign out the prior user.
my goal is to give my customers an option to lock their App's Data, so when they give their iPad/iPhone to someone else for an extended period of time, users can't access or accidentally look at confidential data.
[Some Background: It's a medical Application where physicians/staff-members would give iPads to patients. Now the patients are supposed to access some contents, yet shouldn't be able to look at other patients data]
So far, I have a password inside my App. But when a staff-member forgets and wants to reset it, the only thing I can do is "deletion of the whole database". I have a Disclaimer telling people to store their password somewhere, but this is still not the optimal user experience.
Is there anyway I could authenticate the user via his Apple-Password? This way only the person knowing the Devices-Account password can access the data and can always reset the Apple-Password with Apple.
PS: Server-Solutions, like having a User-Password pair with reset-via-mail on a server of mine is out of the question, since it would add to much complexity for the users and in many medical situations the Device shouldn't have access to the web.
Multiple thoughts:
I am not aware of any native public API to authentication using Apple password.
If your app is enterprise app, possibly you can use native private API. I would recommend to disassemble AppStore and check how does it do authentication then
You can also to try to access to some Apple web page which requires authentication and pass to it apple account and password and see what it will return. If it authenticated correctly, then you are fine and you can reset a password.
To make it secure, you will need to ask a user to enter it for a first time, so you can encrypt your encryption keys using authentication material (so you can decrypt encryption key later on).
However, I am not very big fan of this solution, since you can change Apple password and you will be stuck in such case.
Server solution is the best option and it's not that complex. Another option is Forgot password. You ask something what administrator know ("What is your first pet?") and he enters the answer when your application is configured and this answer could be used later to unlock your app.
P.S. And the best solution at the end (which is absolutely shameless self advertisement). A startup which I am part of (SpydrSafe) works on the product which solves exactly your problem. In fact, healthcare is one of the verticals which whom we actively works. If you are interested, contact me (my email is in profile)
if you authenticate the user via apple password, and they forget their apple password, then in order for them to retrieve that password is by reset-via-email .... so either way you are stuck with that dilemma.
As for actually using your apple password, no.
Best way to get what you want is to have the password stored somewhere in real life. Like another computer that the doctors can report to and ask for passwords or just don't forget the password.
I'm about to use one of those multi-provider authentication frameworks Opauth or Hybridauth (don't know which is the best but I had a little preference for the second one) so the consequence is that I have to manage multi account.
In fact I already have my own account management (login+password+email) and I had last year facebook users. Now I will have to deal with Twitter account, linkedin account, etc...
So the question is easy : how to manage the username ?
For instance, John create a account on my site. So "John" login/username is taken. But if another John from Facebook then another one from Twitter arrive, what i'm supposed to do ?
In Stackoverflow (or elsewhere), what is the practice ?
I don't want a John write on the behalf of another John. Today with my own system, I verify that the login (username) is unique. If not I reject the user. But now ?
I thought that I can check the email but... I learnt that email address can't be the key because of Twitter that doesn't give it to you.
Hope I'm clear enough :)
regards
As you say it's not possible to just retrieve the username from different sources and just store it. I don't know how it is done here in stackoverflow but if you try to register the name is optional so probably it is not an unique key. I can't see the way to login with twitter here so I bet that email is a unique key.
I'll try to answer your question but I've only used facebook API so maybe this can't be done with others. I suppose that each API gives you something you can store in your database and use it later to identify your user against their API.
If you allow users to register with facebook (or gmail, twitter...)then you can use the next approaches (I'm sure there are few more):
They always login with facebook (or twitter, gmail...): you store a record for them inside your database with the key provided by the API and other useful info you can collect. As you said each API gives you different things so you have to think in advance what you really need to provide your users with a good experience: is their name needed? age? If you need more data than the provided by the API you should jump to the next approach or prefetch it and make it editable before. Here you don't ask your user for a password so they can only login with facebook not with a login form, if a user tries to authenticate with facebook (or twitter, gmail) again you know which key you have to look for and authenticate your use.
The can create an account and link it with facebook (or whatever): you ask for facebook permission and then prefill a form for them to provide the data that is missing (password, mail if they use twitter...) and then create the record storing the unique key provided by the API as well to proceed exactly as step 1 if they use their facebook accounts to login. If you asked for a password and an email they can use a standard login form as well.
You can use the first approach and ask the user to change the attribute that is in conflict with other user (name in your case) or even ask to fill what is missing depending on which social network they are using to sign in. You can use name+surname as username to reduce the colission possibility if this is what you want to store to identify your user.
Hope this helps
HybridAuth gives you an excellent way to integrate your site with the social media...
http://hybridauth.sourceforge.net/
This should also help...
I'm working on an app where I'd like to be able to do things with a user's Facebook username. I know that I can get this through the basic user object, but I'm worried about the case where the user doesn't have a FB username when they register with my site/application, but does gets one later. The question is how to test this with FB test users:
A user (a regular user, anyway) has to be verified before they can get a username. Is it possible to verify test users?
If so, is it then possible to give a test user a username?
Is it possible to change that username as part of the testing process (on the chance that my code doesn't work perfectly the first time :)?
What I'm thinking of doing is setting up a realtime subscription on "username", which I've established is possible. If the user above suddenly gets a username, my app gets notified and I can do whatever I do with it. But that implies that a lot of other things are possible, which they may not be. I could retrieve and check the user object on login and keep updating the fields, but I'd prefer to avoid that if possible. Any advice out there?
You cannot claim usernames for test users. You will have to use your own account or test with a real fake account, which Facebook frowns upon.
My iPhone App connects to a web service using a username and a password.
I prefer to save the credentials in the Application Preferences (settings bundle) like the Mail App. Is this secure enough? Is it possible to save those values to the keychain (via Application Preferences)?
Edit:
I want my users to enter their credentials in the Application Preferences of my App. Normally, I can retrieve this data in my app with NSUserDefaults. But Application Preferences saves the data as plain text and it's neither encrypted nor hashed. Is there a safe way? Eg. I know the keychain on the iPhone and I find it great! Can I use the keychain to hold the credentials entered in Application Preferences?
Food for thought: How does Apple do it? I mean, when I want to use the Mail App, I provide my username and password in the Application Preferences. Are those values stored as plaintext?
Did you check the keychain documentation? On the security, see this white paper by the Fraunhofer SIT institute.
Keychain Services will be required for secure storage. Using NSUserDefaults will not secure your data.
You can save it securely using Security.framework.
It is very nice sample from Apple where many aspects of using that framework are discussed. I advice you to look through it. Here is the link to that sample: GenericKeychain
This sample shows how to add, query for, remove, and update a keychain item of generic class type. Also demonstrates the use of shared keychain items. All classes exhibit very similar behavior so the included examples will scale to the other classes of Keychain Item: Internet Password, Certificate, Key, and Identity.
It seems that many people do not seem to understand your question. Unfortunately I can not find the answer myself. The question is how do you use the keychain AND NSUserDefaults at the same time.
I too would like to use the NSUserDefaults interface.
Hopefully we can figure this out...
One option would be to store just the username. Then when the app starts if there is no password in the keychain or if there is a wrong password in the keychain--ask for a new password.
You can remove items from NSUserDefaults when your app runs after the user uses Settings to enter them into the app's Application Preferences. Then put them into the keychain. But these items may be in plain text in storage in the interim(depending on which iPhone model, some may encrypt the flash storage and the backups), before you can remove them from NSUserDefaults.
Apple owns the entire OS and of course the Mail app. They are using features outside of the public SDK, because they can. How do you think the Mail app can run in the background and keep checking for your mails? Normal app can't achieve this :(
Back to your main question, using keychain is the right way to go. But you probably have to disallow users to enter username & password in Application Preferences. There is no way to secure that.