I'm building an app that uses OpenID for authentication. I'm giving Google, Yahoo and the general OpenID site as options.
At present, when the user selects a site, I open a UIWebView and the user performs their login with that frame, all within the app.
However, it has struck me that when using UIWebView, you cannot easily show to the user that the connection is over https or that they are indeed at the site I'm claiming they are at. I could be easily harvesting passwords.
Would it be, and I'm looking for opinions on this, be better from a user confidence perspective to actually open Safari when the user selects a login and once they've logged in have Safari direct me back to app?
Thanks
Most people using iOS devices are used to the way Facebook logins work; no URL bar, no nothing. I'd just follow the typical workflow. You could bump out to Safari, and return via a custom URL scheme. However, I think users will think that is more weird. iOS users are not used to being jumped in and out of different apps.
just my 2 cents, it would be also faster if the user has already logged in those services with Safari before.
Prompting out a UIWebView and switching to Safari is using the same amount of steps, so why not?
I thought I'd follow up on this thread to say I'm having difficulties getting the app approved and I think it's because I use the Safari approach. I've had it rejected by Apple twice now because:
"Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected "
I think it's because I'm launching Safari. I've opened a dispute with Apple and I'll come back with more information once I hear back from them. I really hope a quick change to a UIWebView will help!
Related
I have a website which allows login via facebook functionality and displays photos from facebook.
While accessing from a mobile browser I would like the website to automatically login(when the click on FB login button, without entering username and password) if the user is already logged in via the native FB application (iOS or andriod). It seems to be that I can do that by building a native iOS or android application and use facebook single sign on feature. Is it possible to do that without having the user install anything on their mobile device?
That is not possible.
Auto-Login relies on auth tokens that will be granted to a website or mobile app after a user approves an app. For security reasons, those tokens are tight to the cause they were issued for. Particularly, web tokens and mobile tokens are not interchangeable.
So you could build a native mobile app to get a "native token", but even if you would manage to (cookie-)inject it into a browser view, your website's backend couldn't use it.
More generally, you're raising an issue even facebook can't solve: Say you are using a facebook mobile app and logged in there. If you open facebook's web version on that very same phone, you'll have to log in there again. The root cause is the same as with above. Specifically, any native app is uncapable of setting arbitrary auth cookies into the OS browser. I personally believe this restriction will not fall, because it would have a large security impact - just imagine how any app could set (and possibly get) cookies for any website.
If they've never logged in facebook from their Mobile, how will your website ever know them ?
Is it possible to do that without having the user install anything on their mobile device?
Like PC's, users in a mobile device need to login in their phone in facebook's website before being eligible to login "automatically" to your website. When I say automatically, I mean they still have to go with the first time process of "Do you authorize this app/website to do X things on your account". That message is inevitable when using facebook's api on the web.
Hope this answers your question.
Is it possible to do that without having the user install anything on
their mobile device?
No this would not be possible. You need to have a native or hybrid app (phonegapped etc) to make it work. Mobile web apps run in a browser sandbox and without native code interface - you cannot get to the native SSO of FB on your mobile device
Did you have a look at this facebook page ? I'm not sure what you ask is possible, as basav said, but maybe you'll have some clues there.
I have developed an iOS app that allows users to login via their Google Account using OAuth.
It was rejected by Apple for allegedly violating 11.13 of the App Store Review Guidelines:
11.13 Apps that link to external mechanisms for purchases or subscriptions to be used in the app, such as a “buy" button that goes to a web site to purchase a digital book, will be rejected
Upon asking for more information, Apple said:
To clarify, your app has been rejected for including means for users to acquire new Google accounts. Linking customers to a page where users may sign up or register new accounts, and then use those accounts to purchase service/server space to be used within the app, is not appropriate and must be removed before resubmitting your app.
Here's a screenshot of the infringing functionality:
The Gmail iOS app has the same screen and I can't find any other app that connects to Google by OAuth so I'm at a loss on how to fix this.
Any ideas?
Many thanks!
EDIT: Here's a screenshot of same offending screen in Gmail
Edit
Google has finally added a native library that performs in-app sign in. You can find it here https://developers.google.com/identity/sign-in/ios/start
Original Post
This has happened to several users and unfortunately Google are still "working" on a solution.
I would strongly recommend that anyone facing this issue please comment in the official forum. The more attention it gets the higher the chance something will be done about it. Here's what one of the employees at Google had to say:
Hi all -- at Google, we aim to make our services available to as many
users and developers as possible. We have heard a very small number of
reports of problems of this type, but those app developers appear to
have eventually gotten approval to launch by working through Apple’s
standard process.
Meantime, we're continuing to work on improved mechanisms for login. I
do agree with Daniel that direct use of GTMOauth2ViewControllerTouch,
or the equivalent UIWebView trickery, is not recommended.
Right now the solution I used was to remove Sign In from the Launch Screen and move it to the menu inside our app.
Place a link mentioned below instead of SignUP button:
https://accounts.google.com/SignUp?service=mail&continue=https%3A%2F%2Fmail.google.com%2Fmail%2Fca%2F<mpl=default&hl=en
This link should be open in iOS Safari browser.
I had the exact same thing happen to me, but for a different service (SmugMug). In my situation, I worked with SmugMug and they provided for me an OAuth authorization page that didn't have the sign up button.
Some months ago, same thing with Dropbox. Dropbox also ended up providing a login page without a sign up button temporarily, but they got a little more cooperation with Apple.
Perhaps we can try to collectively get Google to provide the same. Even though we're iOS developers, Im' sure Google wants to support development of iOS apps that use their platform.
Have you tried contacting Google?
I have seen many web apps supporting Facebook Connect...
But when i login through those apps sometimes the authentication is successful but nothing is returned to the app and the login page just goes to a blank page in that new windows and stops... The whole process fails... And this has not occurred once but many times...
So my question is:
Is Facebook Connect a good solution to use in apps or should i use something like Google Login or Twitter Login or OpenID or just a simple password based login or all of the things and let users choose what they want?
And if your answer is app the solutions then wont my database become messy and the app slower because it has look for more data now?
I know it depends on various factors but I just want your opinion, what would u choose and why?
Supporting Facebook connect as login function make sense only if your app has something to deal with Facebook (which is the most of our app today ;-)).
The behave of some app when sucessfully Authenticated and then Authorized is up to these app.
FB login give you all the tools to build you own user experience.
The things become a bit more difficult when you want to introduce FBConnect within already existing login base, while you have to find a way to bind the Identified FB user with your user account.
I'm building an iPhone app that has some social features. I've managed to get the user to log-in to Facebook within my application.
I've also implemented a webview that loads a facebook iPhone-optimized page. What I now want to do is my user to be logged-in within the webview without having to log-in twice (once in the app and once in the webview)
I've tried a few things playing around with the access_token in the URL but it didn't work.
Does anyone know if it is possible to implement that and how to do it?
Thanks in advance for your help
Short answer: You're probably not supposed to be able to do that.
The idea is that your app should only store an authentication token that lets you do stuff as your app (e.g. post to the wall as your app). On the web version, the user is logged in to facebook and facebook additionally passes an authentication token to your website; on the iOS version, I think you never get the Facebook session cookie, and I'm pretty sure you need the Facebook session cookie to be logged in to the web side of things (especially since it's designed for the browser — logging out of Facebook logs you out of Facebook Connect on all sites).
There are loads of things you can do to work around this — it's trivial to just ask the user for a username/password (and the whole idea of a "trusted UI" inside a UIWebView inside your app is flawed, despite Facebook's claims).
The "right" thing to do is to implement everything using calls to the iOS SDK so you don't have to bother with the web side of things.
were you testing your app on the simulator or on the device? The reason i ask is because im trying to get the app to stayed logged into fb which it does, sorta...it still pops a fb dialog saying it logged in fine and the user has to click on an OK button.
I havent had time to test it on the device but i think it may have to do with the fact that with the OAuth 2.0, with 3.2.x or >...if the fb is installed, it uses the fb-app login but if its not installed it uses the safari web login.
Since simulator doesnt have the fb app installed, it actually uses the safari web login (i humbly deduced) which would otherwise store a cookie and maybe it doesnt do so on the simulator..dunno, im still looking for the answer on that one :)
I'm trying to glue information from a web page to an iPhone app that said web page suggests to download. I control both the web page and the downloadable app.
Scenario is like this:
User visits my web page, on which I recognize the user (he may have logged in, and I store his info in a cookie). I then present a link to him to an app in the App Store that he should download for "enhanced experience" of this web service of mine.
Now, when the user launches the downloaded app on his iPhone, I like to re-identify the user who previously visited said web page.
All would be easy if an iPhone app could read Safari's cookies. But it can't.
A somewhat lame solution could be that the web server stores the visitor's IP address and uses that to recognize him once he launches the iPhone app. But that's not reliable.
Another one would be to give the user a token (code) that he needs to remember and then re-enter in the app. Still quite awkward, I think.
Any better suggestions?
Simply put, you can't do this.
One thing you could consider is a custom URL scheme to launch the app. You could send the user an email that uses this custom link. However there's a couple of problems with this:
the user may not have the account that they used to register for your site set up on their iPhone. This might seem unlikely, but say the user signed up for your site 5 years ago with their Hotmail account and they have since switched to Gmail.
it's unlikely that the email would fit into their workflow. They would probably download the app and just launch it by touching the icon instead of clicking a link in a received email.
You could also put the custom URL as a link on your web page, but again, this won't fit into the workflow because they have to go to the App Store app to do the download.
Consider this - if you've got some sort of website that has an authentication step, it's probably a fair bet to say that the user is the type of person who already has an application such as Facebook installed on their iPhone. They are already used to the paradigm of having to enter their credentials into an application despite the fact that they may have already done it in Safari.
If you could read the unique iPhone device ID from javascript on your web page, you could look for that again when the application connected...
But I cannot find any means of reading this from Javascript in Mobile Safari, I thought I'd post in case there is a way now to give you another option to consider.
OK, we found a somewhat working solution: The html code can create a cookie. Later, when the app runs, it can't directly read that cookie, of course (due to the sandboxing of iPhone apps). However, it can connect to the server, then open a http URL pointing to the server and including a unique token that it has gotten from the server beforehand. This leads to launching Safari, accessing the server. The server can now read the aforementioned cookie and finally establish the connection with the help of the token.
Just stumbled over this question and I'm curious if you thought about using a UIWebView.
Where the question is - does UIWebView share cookies with safari?
If it does the rest should be easy.
UIWebView's DON'T share cookies with Safari. So unfortunately that is not an option.