I would like to know if there is a way to find out before I send the authorization request if a user is signing up to my app with Apple for the first time, or if he/she is already registered and just signs in.
Basically I have a registration screen in my app, where a user can create two types of users and a login screen where both users can log in. I would like to keep the registration and login separate, so for that I need to know whether its a first sign in with apple.
I'm not sure what database you're using but for Cloud Firestore there is a Sign-in method that can be used with Apple.
Related
I'm creating a book library app, where people buy an account and become able to read all the books...
In the past, we were able to get the UDID of the iOS device and the login only works from this specific UDID.. now apple prevents this, another solutions were there like OPEN-UDID but now doesn't work...
Are there any other means to prevent the user from giving the credentials to another people??
The only solution on top of my head now is this :-
When a user login, a flag on the server becomes true, and when another account try to login using the same credentials, it will show an error message "you are already logged in on another device".. when the original user logs out, the flag becomes false.. this will prevent the account from being used on multiple devices at the same time.. but the drawback is, what if the user unInstalls the app without logging out?
Is there a research on this topic that covers all these scenarios?
Is there a way to use apple keychain or iCloud or any other solution ?
What you can do is on new login invalidate api request(and send them to login screen) of previous login you can use device token with each api to check if you want to send data to device or it's a old login token and needs redirect to login. you have to just store a device token for each account login if it matches then send data else redirect to login
Edit 1:
if you uninstall the app then you have to login again from other device to access the books(data) and in each login you'll replace the old token with new one. Now only device which has this new token can access books. All other device if there are any login left in any device then they will get message from API that token not matched and you have to redirect them to login page again
Background:
I am developing an IOS app using firebase as backend.
There are 3 authentication:
1:password and email
2:FaceBook
3:Google
I have checked the option "one email per account" option.
The situation is:
Say if I first sign in with one of the Auth provider and later, log out, and want to sign up with any other two Auth providers. I will get an "the email address has been used" error if the associated Email of the current provider is the same as previous. In this case I want to link the current Auth account with the previous account.
I understand that I need to call the linkWithCredential:completion: method to link the accounts. But I first need to sign In the previous account but how can I tell which account to sign in? For example, if I log in via Facebook and get the "same email being used" error, how do I know at this point whether should I sign in via Google or the email/password?
One interesting thing is If I use Facebook or email/password to sign in first and later sign in with Google, firebase will automatically handle the linking but the default behaviour is to overwrite the previous Auth provider with Google and keep the UID...
I have found an useful post How to manage users' different authentication in firebase
But it only deal with a simpler situation where authentication are only two.
When you get the credential already exists error, you already have the email at that point, you then call fetchProvidersForEmail with that email which will lookup the provider IDs associated with that email. You then sign in the user with one of those providers. After you finish sign-in with the existing account, you call linkWithCredential:completion: with the original credential that caused the error to occur. This causes the accounts to link. The next time the user tries to sign in, they will be able to sign in to the same user with either provider.
Check FirebaseUI-iOS which already takes care of the whole flow for you. You can also check there source code to see how they handle such situations: https://github.com/firebase/FirebaseUI-iOS
I'm working with AWS Cognito. I have my sign-up flow working just fine. They user fills out their email addresss and password and I create the account in the proper User Pool. I have email verification enabled, and the email is sent and is received in short order. After the Sign Up screen the user is presented with a verify screen to accept the code that was just emailed. Again, this all works great.
What I am trying to understand is:
Once I have a user signed up and verified, in order for the iOS AWS SDK to do it's thing, so I need to then tell the user to go sign in or am I just missing some call that can grab their credentials once they are verified?
My guess is, since we don't know when the user verified themselves, it could be hours later and they could have killed the app and restarted it in that time that the expected flow is to have them sign in again.
Since the app does have the password in memory (NOT stored anywhere on disk) that they used to sign up in the current signup navigation controller/flow I supposed I could just force the sign-in after the verify completes.
I just wanted to make sure I didn't miss something in the SDK or it's docs about this case.
Your understanding is correct, there is no verification flow that will skip sign-in. One option would be to keep the password they used to sign-up in memory and if they verify immediately use that. If they come back some time later or restart the app force them to sign in.
I have an app in which i want to only add a logIn button. No signUp.
I am thinking of it like this please tell me if this can work?
SaaS based. So if a business wants to use app, they must sign up on website.
once they do, they can download app where i will give them their logIn Credentials.
Therefore if someone downloads my app from the app store they cannot register unless they are a SaaS customer. Only LogIn with the credentials i provide after signing up and paying for the service.
This being said, if this is doable. i used the parse swift signup code to get my classes working on parse.com
If i go into the users class, i can add new usernames and passwords. (Great!)
If i delete the SignUp code now from my app, and add the LogInUserinBackground code will it still work for logging in users so long as i add their credentials on the Back-End?
Thank you for all responses! Much Appreciated.
Yes, that can and will work.
You can of course remove the ability to create users via the app and only support the creation via the application. Just set the user up via the website, assign the username and password and you are ready to go. Of course you have to create some kind of login form inside the app - what you cannot do is customize the application one user downloads to one specific SaaS customer so that he gets logged in fully automatically. At least once the user has to enter the user credentials in the app.
And as far as I am informed that is even allowed by the app store guidelines - you only have to make sure apple gets a demo account when submitting the app in the end.
I have recently implemented login to my via facebook connect. So now users have 2 ways of logging in to the site. The old way of registering an account and the new way (facebook connect).
One thing I would like to do is link a new facebook connect user account to existing accounts if they logged in the old way.
Has anyone had any success doing this?
Very good question I think and lots of people will benefit from an answer.
What you need to remember is that accounts are only linked so long as they are authorised to be linked through Facebook. What you should do is maintain a second table of linked accounts in your database so that you know who is who and if they are linked with Facebook.
You should read this integration comment, it provides a lot of useful information.
http://crazyviraj.blogspot.com/2010/01/test-cases-for-basic-facebook-connect.html
It doesn't really say how to do things, but it makes sure you tick all the boxes of what you should be doing.
ie:
Sign Up should fail if the user denies
permission to the app (category: sign
up)
Since we need access to an email
address, Sign Up should fail if the
user provides publish permission but
denies email permission (category:
sign up)
If the user provides an email address
that already exists in your system,
fail Sign Up. Make sure no YouFace
backend tables are modified (category:
sign up, 1:1 mapping) PS - when this
happens, I didn't find a way for you
to de-authorize YouFace on the
Facebook user's behalf. The user must
manually do this if they wish you use
the same account but provide a
different email address.
Accounts created using Facebook
Connect should not be able to login
using YouFace's default email/password
login system (category: sign in,
account security). PS: Since YouFace
accounts require a password and those
created using Facebook Connect don't,
make sure to insert a random password
hash into your table to avoid silly
errors
Accounts created using YouFace should
be able to sign in without requiring
to be signed into Facebook, even if
when a link to a Facebook accounts
exists (category: sign in)
Any many more
You should be asking for permanent access through fb connect authentication. Once you've done that, you'll get a token which gives your permission to access someone's Facebook information, and that token will not expire unless the user explicitly removes you from the permission list or changes his/her password.
Once you have the token, associate that token with the user / create a new field in your user table to store it.
To associate the user with a Facebook account without the user logging in, you can try to match by email. It's not 100% accurate but it's pretty good. Facebook doesn't give you email addresses in text form but you can get email hashes from FQL. Since you already know user email addresses, you can calculate the hash for all of your user emails and search through your user base for matches every time a new Facebook Connect user signs up.