When I implement OAuth in iPhone, I have a dilemma to choose Safari or UIWebView to open the Twitter pages for user authentication?
I write some advantage and disadvantage of both case:
Using UIWebWeb. The disadvantage is users have to enter their credentials in our application. It's maybe risky phishing. The advantage is this approach will not quit our app.
Using Safari for user to authenticate (this approach automatically callbacks to our application) Addvantage: less risky. Disadvantage: have to quit our app
A good reference link about this: http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice
Which approach do you prefer?
Any response is appreciate. Thanks.
The vast, vast majority of users will not understand or care about the distinction. Do whatever makes their lives easier, or--all else being equal--your life easier. And so long as you are trustworthy (you're not phishing or peeking at their credentials, right?), you'll be providing a good experience and not screwing them over. In this case, I'd use the UIWebView.
The guy who did the Pownce iPhone app a couple of years ago sort of publicly debated with himself about this.
His blog doesn't seem to be up anymore, but basically he implemented it the "right" way as far as OAuth is concerned. Instead of entering credentials inside of the app, Safari was launched and they were entered in there, and then a custom iPhone URL was used as the callback to relaunch the Pownce app. Pretty neat, eh?
Some time later, the developer followed up with a comment that a lot of people were downloading the app but not actually using it. His conclusion? That his brilliant OAuth scheme was to blame. Users were confused by Safari launching and being taken out of the app.
To be honest though? I think the fact that the app was for Pownce, a service that nobody used, was to blame.
I have an app in the app store right now that uses the Foursquare API, which supports both Basic HTTP auth and OAuth. I decided to "do the right thing" and use OAuth. The user enters their credentials directly inside of my app. Am I saving their username and password in plain text anywhere? Nope. But could I be? Sure.
It might sound like I'm arguing for both sides here, but what it really comes down to is that it's very unlikely that your users will know or even care about what OAuth is. It's probably just as unlikely that they will even think twice about putting their credentials into your app. OAuth is great (a hell of a lot better than OpenID) but wasn't designed with the iPhone in mind. It's built to work inside of a web browser. I think the Foursquare API docs put it best when talking about their Mobile/Desktop client OAuth scheme (different from what they want you to do for a web app) - "We provide this mechanism under the assumption that if a user has installed your application on their hardware they, trust it enough to pass through their authentication information to foursquare."
I've already implemented this as a drop-in set of classes (open source). Feel free to take a look: http://github.com/bengottlieb/Twitter-OAuth-iPhone
For the best user experience with destop and mobile application, we should use xAuth:
http://docs.google.com/View?id=ddkz8b2q_76d95356mz
As of May 31st, 2017 and onwards, there is no option left. We MUST use Safari, since google now does not support OAuth via UIWebView. Refer this link for more details.
Related
I've got a client that wants to have a paid app providing his video instructional content on iOS, but of course we dont want people simply getting the video content directly without paying for the app.
Is there some simple way of doing this that I'm overlooking? He wants the content streamed so he can add content easily and periodically without app updates.
Perhaps using Youtube but having the videos password protected? Is there a service anyone has used with an appropriate iOS API that anyone has heard of?
I've never done this before, but you could do some kind of token exchange based on the device ID. When the app is first used, register the device ID with the content server, and use that in combination with a salted hash of some kind to identify the device when requesting the media from the server.
I'm considering two options right now.
1- Following this post (roughly) In iOS, how would you programmatically pass a username / password to a secure site and essentially doing a combination of .htaccess for password protection, leveraging robots.txt to prevent search engines from indexing the videos, and obfuscating the video names. I've got to research the password protection of the video directory and how exactly to do that... but it seems the simplest. The downside is the clear text password.
2- A slightly more sophisticated method where I use oAuth to authenticate against but really following the first path, and potentially leveraging http://maniacdev.com/2010/09/new-open-source-oauth-library-for-easy-authentication-on-ios-devices-from-google/ to help in writing the oAuth piece.
a third possibly prohibitively expensive option is to look at the HTTP live streaming in OSX server https://developer.apple.com/streaming/
How do you guys think these options sound? Are there others I'm not considering?
I'm trying to block all the PC, laptops and send them to a blank page or any page that I set it up for a PCs site.
I just have a mobile version website and I only want to allow iOS such as iPad, iPod and iPhone to visit my website and block the rest for my security purpose
I'm trying to search in here and google I think I'm using some kind of wrong term or maybe something that I don't know exactly but I see many website does that.
Thanks
I would just scan the user-agent. Find the ones that you will accept and then redirect the rest to a non-blank sorry page. A blank page would not be very nice, so a simple sorry would do. I say this because maybe the user has a mobile device to use, but happens to be on a pc. A blank page would make them think that the site is junk or doesn't work and you might lose their mobile traffic also.
block the rest for my security purpose
How secure does this need to be? You shouldn't trust the client to always tell you the truth about what they are.
I suggest you use some other mechanism to ensure security, for example username/password.
I used MobileESP to detect when someone using a smartphone connects to my website. This uses PHP, and has some functions to make it pretty simple. I'm sure you can accomplish it with the above methods, but in case this would be of some help...
http://blog.mobileesp.com/
Under iOS there are several built in hooks for launching service-specific apps based on a passed URL for example handling http:// (to Safari), handling addresses (to google maps) and phone numbers (to the built in phone app). Several apps make it a standard practice of implementing the rarely used ability (for most apps) to register your own service prefix. Two handy apps that come to mind that implement this are facebook:// and skype:// and it is a handy way to add quasi-integration with their app into yours. Skype even does this on most desktop os's so you can literally run the command line skype://555-1234. You can also check for these registered service prefixes and expose useful menu choices in your apps but I digress.
As with all of these service handlers built in or not, the problem under iOS is that you lose the user and the flow of their experience ends with the phone app (for example). Yes you can embed web views to handle some cases but things like the phone app still win out.
I propose that it would be great that if iOS apps were handed a trailing URL as part of their arguments (even if they accept and might handle say two args already) that by convention when our app is exited we launch the trailing URL we may have been optionally handed. If fully supported in some manner this would allow for multi-app integration and an extended user experience flow-wise. I'm imagining being able for example to launch a phone call and have the user return to my app when it is finished by launching my app again using the URL I passed it such as "myapp://return-context-values". Obviously this could be taken further.
Does such a mechanism already exist in some way? If not I'd like to hear your thoughts on the idea.
Check out x-callback-url.com, it proposes precisely what you're suggesting.
And yes, I think it would be great. You're much more likely to pass a request to me if you know you'll get the focus back, and vice versa.
I'm pretty sure that due to the Application Sandbox, none of this is possible, but...
I am working on an application that operates on text that the user inputs. Aside from forcing the user to copy and paste from another application or type in text, what other options exist for getting text? To be more specific:
Is there any way to get the user to "pass" an email to my app? I can imagine a hacky solution where I have the user mail it to a server on the Net, and then I expose the mail from a server-side application, but I'd like something a bit more direct.
Is there any way to get to the user's mail inbox without asking them to put in their credentials?
Is there any way to plug-in to Safari, so that I can send web pages "over" to the app? I don't mean a full plugin, which I know is impossible.
I'm trying to think of creative ways to solve this problem of how to get text into my app, so any ideas would help.
From the Iphone SDK Forum: "Apps can't read each others files - but you could use a URL scheme to launch one app from another. Any parameters in the URL would be passed."
It's what my gut was telling me, but i wanted to go verify before saying..officially, no. The Sandbox isolates each program..
You can pass via URL text strings, but that's about it. I haven't seen any app which hacks around this limitation, but that just may be none of them surviving the app submission process.
http://www.iphonedevsdk.com/forum/iphone-sdk-development/21099-sharing-data-between-applications.html
We have a web application and we've built phone applications (iPhone, Android, BlackBerry) to be companions to the site. The usual workflow is that an existing user of the site gets a phone app and then plugs their existing credentials into the phone app and they are off and running, but more often now we are seeing folks who are downloading the app and then (and this should not surprise anyone) don't read the help screen that explains they need to go and get credentials at the web site and therefore cannot connect to the application which does require registration to manage their content. This is a giant usability fail condition.
So we know that we need to put user registration workflows on the phone app.
Other than the obvious solution of duplicating our registration page on the mobile, does anyone know of a better identity solution for the phone? For example, on the desktop we also use Facebook Connect as an identity server and the users love it. I'm looking for something that simple that we can implement across the major smartphone platforms.
Clarifying note:
I should add here that this registration mechanism is likely to; and it would be desirable if it did, go hand in hand with a general identity/authorization mechanism such as the Facebook mechanism mentioned below.
One other place I'm poking around is to see whether there's an openId solution that does not require a browser to pop up.
Restful service might be the e asiest way for you to achieve this, you can use it on any device that can make http requests, so you can make your own login screens and talk to the s ervice that way...
Facebook has a Connect API for the iPhone. Integrating it into your iPhone app is very smooth.
http://developers.facebook.com/connect_iphone.php
On the BlackBerry we were able to build a fairly robust REST pipeline between the client apps in the field and our servers. We primary use the framework for updates, but the device API is generic enough to be able to build almost anything you need via standard HTTP/HTTPS GET/POST calls.
On the RIM platform, look into the HttpConnection API as a starting point. There is also an example on the BlackBerry Developer's site which will help. Finally, I believe there are several examples inside the sample package that comes with every BlackBerry JDE (IDE + API download).