I am building an iOS app with a web component. The web component will simply be a website that will allow users without accounts to perform a basic action like sending text to another user. I am using firebase as my backend so for the web component I'm anonymously authenticating the visitor. Once the user completes the action, I log their action in a database (hence the need for authentication) and give them the option of downloading the app, where they will make an account. My plan is to then convert their anonymous account into a permanent account on firebase.
The problem lies in the following:
I want to somehow "know" the user's authUID/web session once they leave the site and download the app in order to either a) pass their anonymous session and convert it to a permanent account once the user completes the sign up (email, password), or b) have their authUID so I can match them to their anonymous session and transfer their logs to the account they create upon sign up.
I feel like I'm overcomplicating this; the premise is: web visitor does something, downloads the app, i match the app user to the web visitor to sync their data.
I have tried using cookies but from what I've read, it is not possible to view cookies in safari since iOS 11. Is there any other way to transfer information between safari and an app?
Related
I have a website providing functionality for Google Sign In. There is a server side authentication taking place after getting idToken on client side.
Now I am making an app(in FLUTTER) for the same website. In Google API console, I have to create new credentials under the same project and that generates new client id.
I read about cross client identity (Link: https://developers.google.com/identity/protocols/oauth2/cross-client-identity). I want to know how can I implement this so that a user is asked for approval only once.
Do I really need two client ids?
This will work even if the web app and mobile (Flutter) app do not have the same client ID. This is stated in the documentation here:
Google considers that when a user has granted access to a particular scope to any client ID in a project, the grant indicates the user's trust in the whole application [i.e., all clients in the project] for that scope.
You should make a project that contains multiple clients. Your Web app will be one and the Flutter app will be another. These will end up with different client IDs, but that's OK. Later, when the user authorizes (consents to) a scope from the Web app, they will still authenticate in the Flutter app but not have to reauthorize this second client to use the same scope. The reverse is also the case -- if the user authorizes a scope in the Flutter app first, they will later have to authenticate in the Web app, but they won't have to consent to the scope.
I have an app with SwiftyDropbox that function correctly, but I need to insert email and password for Dropbox every time that I use the app.
The app it's only for my use, it's not a security problem if the app auto-login in my account.
I don't find examples or documentation to make an auto-login with SwiftyDropbox. It's possible?
While the Dropbox API was designed with the intention that each user would link their own Dropbox account, in order to interact with their own files, it is technically possible to connect to just one account. We generally don't recommend doing so, for various technical and security reasons, but those won't apply if you're the only user anyway.
So, there are two ways to go about this:
1) Implement the normal app authorization flow as documented, and log in and authorize the app once per app installation. The SwiftyDropbox SDK will store the resulting access token for you, which you can programmatically re-use after that point each time using authorizedClient.
2) Manually retrieve an access token for your account and hard code it in to the app, using the DropboxClient constructor shown here under "Initialize with manually retrieved auth token".
I am working on my first app so I am not so experienced with this stuff yet. I have figured out how to send a POST request url to a php page and process the php to register a new user in the mySQL database or log in to the app by connecting to the database to see if the user exists.
First off, does that seem correct? To just send the request to register a user with text field variables and to log in by checking if the text field information exists in the database or should I be implementing some other ways to do this?
Second, What should I be doing once the user enters in his credentials in order to tell the app that the user is logged in so that if the app closes down and the user goes back to the app, it will automatically log the user back in.
That being said, the way this app is going to work (as of now) is the user will log into the app, and the log in view will go to a different view but then the user can log out and it will go back to the log in view. Once I can tell the app that the user is logged in, I should be able to tell the app that the user isn't logged in anymore.
How you implement your database security is up to you. I would recommend you route your authorization/updates/gets/posts to an API so you don't need a PHP "middle man" (unless the PHP is your API) and you can send requests directly to the API layer and handle the rest on the server.
As for the plain text part, it is a common security practice to encrypt passwords on the database. On the client side, I'd suggest using the Apple Keychain to store the username/password for future use. In iOS, this can be easily implemented using this Keychain Wrapper if you're using ARC or this one if you aren't.
I have an app that can be accessed on mobile phones, both iOS and Android. The app has a social component to it, so people are sending data to and from my server.
I also have an interface for this app that will be accessible through Facebook.
When logging into the app via mobile device, using the native app for that device, one can just log in with standard username and password.
However, obviously if a user accesses the app in Facebook, they will expect to already be logged in since they are already logged into Facebook.
So I need to make it so that my app can take a log in from Facebook, pretty much automatically (?) for users who are coming at it from within Facebook.
Further, it's possible (dare I say "likely"?) a user might access the interface from both Facebook and one of the mobile versions of the app. In which case I need to be able to ensure that the username/password authentication they use on the device points to the same account associated with their Facebook login.
So... all that said... what kind of Facebook authentication should I be studying and implementing.? I'm looking at their documentation right now, and like all documentation, it's not easy to grasp. There is server-side (authentication code flow?) and client-side (implicit flow?), and authentication tokens, and I'm already a bit lost.
Also, I assume Facebook's approach is to want to take over my login in process completely, not live side by side with my mobile-device-only login, but I'd like to make sure users have the option of not using Facebook authentication if they don't want.
Can someone point me in the right direction for how to do this? Basically let me know which part of the documentation I should be focusing on.
And are there any gotchas I should watch out for?
Your server will receive a signed request when your app on facebook.com is loaded; from this you can find the FB uid of the user.
If you obtain the FB uid for users of your mobile device clients you'll be able to match your app's accounts between mobile device & facebook.com clients.
The bottom of the main authentication docs page gives links to further documentation for different client types. The main mobile authentication page has side-bar links to tutorials & SDKs for iOS & Android. Alternatively you could use the server-side OAuth flow as your devices have browsers that support this.
Once you've completed authentication on the mobile device it's simple to obtain the uid.
You can also use the Facebook authentication flow instead of your own username/password authentication.
I'm building an iPhone app that, in part, allows the user to log in to, pull data, and post data back to a Wordpress site (more specifically, Buddypress). One way I'm considering approaching this problem is to use a series of UIWebViews to display the mobile-themed version of the site.
Ideally, I want the user to be able to, upon first-launch of the app, input their username and password, and then never have to do it again (functionally similar to tons of other social apps out there, like Facebook, Twitter, etc.)
Here's my question - obviously it is easy to store the user's login credentials, but how do I, in the background, establish an authenticated and persistant session with those credentials each time the app opens, so for the user, they are never presented with a login screen again, and can just use the app like normal?
Does anybody have any suggestions?
WordPress uses XMLRPC to authenticate. You can, on top of the API given, write your own codes to store credentials. Persistent session can then be made.
Read this FAQ : XML-RPC Support for WordPress