I am building a paid iphone application which
- shows some premium content videos to the user.
- app loads a page from my webserver in UIWebView
- but the videos are hosted at some other video hosting site.
I realize that, in order for me to be keep this app paid, I need to keep the video links protected/secure (else if the urls are leaked, no one is going to want to pay for it).
I can easily password protect the webpage (pointing to the actual video) and make the user name and password available to the iphone app to access this webpage. But when the user selects the video link, the app will load that url. If user sniffed the packets on the iphone at this time, they could get access to the url and just run it from there directly.
I dont believe mod_sec_download or mod_xsendfile can work in this scenario because the video link is external. Right?
Is Amazon S3 a possible solution?
Would appreciate any insight/solution.
Thanks!
Don't point directly to a video file. That'll make it trivial to steal. instead, point at a proxy script that can check the source of the request and verify that it's coming from a registered purchaser.
With appropriate one-time tokens, tracking of usage, etc... you can keep most people from sucking your site dry. And of course, the best practice is to embed a watermark into the video as it plays, so that even if it gets stolen, you can track it back to the first person to release it.
You might want to take a look at the OWASP Top 10 and in particular, number 8 about failure to restrict URL access. This is effectively your scenario: you have resources which need to be secured at the server level. You can't just do this from the device end, the location of resources requested by the device is easily discoverable.
So it comes down to access controls on the resources, in this case, your videos. How you do this will depend in part on your server stack. For example, IIS7 has an integrated pipeline which can apply access controls to resources of any type such as PDFs, images and videos (more on this in OWASP Top 10 for .NET developers part 8: Failure to Restrict URL Access). Alternatively, you'll need some form of application proxy which can take responsibility for the authentication then delivery of the video content.
This is really more of a webserver issue than an iPhone issue. Focus on getting the access controls right on the server then the iPhone end will be a much more straight forward process.
Related
Is it possible to limit the total number of user installs of a Facebook application using Facebook API or configuration?
Obviously the beauty of Facebook's platform is the virality. However, the greater the number of installations the more server demands grow etc.
So when building applications for clients with fixed budgets (think marketing activity / capping adverts per day based on spend) - is there a way to restrict the total number of users that Facebook allows to install an application?
Specifically talking here about building Facebook Games.
No, there is no build-in mechanism for that – because usually developers are happy about an ever-growing user base.
A canvas app is not really “installed”, users just connect to it. And this is the only point where you could try to handle this – once a user has connected to your app, you can recognize that (via the signed_request parameter or using the JS SDK) when he visits your app next time. So from a certain point on you could just not ask users for login any more (FB.login, redirecting them to the Auth dialog, …).
Obviously your initial app page will still be called, but any stuff you do afterwards with connected users and their data (if that’s what strains your little server most) you could just stop for users that are not already connected. Big downside of this is of course, if a user removes your app (willingly or by accident), they will find no way to re-connect with your app again.
Maybe you should consider hosting your app on a platform like Heroku – it’s free, and I think they will provide you with enough server power to handle your app growing larger than initially planned/expected.
How do I go about loading a splash to the user if they are offline? I want it to show after the initial loading image, I have a page called gone-offline.jsp but how to detect if user is offline on mobileinit?
I'm not using phone-gap
You need to decide what offline means to your business scnenario. This may sounds silly, but it depends on what your app wants to do. For example:
Does your app want to go offline when it is actually offline and can't reach other websites, or does it want be in offline status when it can't access your webservice.
Assuming you want to test that there is no connection to your webservice I would recommend the following:
1) Make an ajax call every x number of minutes to your webservice to check if it is still online
2) make a common method that handles time outs if your application thinks its online and is offline.
3) make it so that when your application is offline, it is trying to get back online in the background by doing a similar step to step 1.
To do ajax with JQuery see: http://api.jquery.com/jQuery.ajax/
Note that if you require cross domain json (you may or may not) then you will need to investigate CORS/JSON-P/XSS with iframes.
it's very simple using javascript.
if(navigator.onLine)
{
//online code here
}else{
//offline code here
}
(done with jQ mobile)
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.
This is really just a "what-if" type question, so forgive me if it is either ridiculous or ridiculously easy...
I have a client whose site offers a "chat with a consultant" option that you see on many sales and support sites. We were wondering if there was a way that iPhone users (or any user, in theory, but mostly iPhone) could click this option and after giving the basic form info (name, question,etc) the actual chat itself could open up in the chat client.
Is this as simple as the "click here to send me an AIM message" syntax?
The XMPP (jabber) server is Openfire and the webchat uses the Fastpath plugin. Would this feature need to be enabled deeper than the page's HTML/PHP? Does the server/plugin need to modified as well?
Would this threaten the security of the XMPP server (which is behind a firewall and can only be accessed externally via the above plugin)?
Does this even sound like something that iPhone users would appreciate, or would it simply be confusing/obtrusive?
Sorry for the objective last question, but I'd hate to spend time on this only irritate users.
Referrals to resources and documentation welcome. I'm not looking for someone to walk me through the whole thing, I just want to get an idea of it can be done and where to start reading.
I'm a little confused by what you want to do - the user fills out a form on a web site and then they are put into a "chat room" on their iPhone?
This is possible. However all of them require that the user has already installed your app, so it may be a hurdle to what you are trying to do.
However if it's using a pre-existing chat service (such as AIM), you may already be OK if the user already has a chat client installed on their iPhone. You could launch the app using custom urls or push notifications - however, this is assuming that the app developer has enabled such hooks, and if so if they are published.
If you want to go with your own client, if the user is filling out the form on the iPhone, then on submission you could redirect them to a custom url for your application. From mobile Safari, this will directly launch your app. Note that the user must already have the app installed for this to work, or else they'll see an error, and it won't be a particularly user-friendly one.
Another way, if the user is filling out the form on their computer, is via push notification. Again, they must first have the app installed. They would receive a notification that, on acceptance, launches your app.
The final way, if the user is filling out the form on their computer, is that they would have to download your app first and run it, so that it could communicate with a desktop client of yours via network services.
I'm working on an iPhone app that ideally uses OAuth to communicate with Twitter. I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The problem is, Twitter has this whole scheme for working with desktop apps, using a pin number. When I register my app with Twitter, they have a web form asking me if I'm a desktop or web client. If I choose desktop client, when I try to have the user authorize, I can set the oauth_callback parameter but Twitter will ignore it after authorization and show a pin number. If, on twitter's form, I specify that I'm a web client, it requires me to enter a URL to redirect to after authorization. And, since I'm using an iPhone app-specific url scheme, their web form fails on validation as it only seems to accepts URLs conforming to the HTTP protocol.
So, it seems like I'm stuck - I can't say "desktop" because I don't want to bother with a pin, and I can't say "web" or I can't use an iPhone app URL. Any solution to this?
From your question:
I know a lot of people are doing the OAuth workflow inside of their apps using a UIWebView, but I don't agree with that and am going with the Pownce approach.
The Pownce article suggests that quitting your application and opening Mobile Safari to perform the authentication step is problematic, and that they started receiving bad reviews from users for doing it that way. They also experienced a failure rate of around 40%.
Pownce's solution is to use a UIWebView within your application instead, so I have a feeling you may have misinterpreted their recommendations. That being said, they do label this as a "naive" solution and go on to suggest a bunch of theoretical "ideal" solutions.
Another point you might not realise is that desktop applications (using the "out of band" / pin number method) and web applications need to open the Twitter site in either an embedded or external browser.
So you've got two choices on the iPhone:
Open up twitter.com in a UIWebView, specifying no oauth_callback parameter or oauth_callback=oob to start the pin-based out-of-band flow. The user then needs to copy the pin using the iPhone's copy-paste functionality, manually close the UIWebView, and paste the pin into your application. The pin can then be used converted to an access token.
Do it how everyone else is doing it (UIWebView + custom-uri://foo.bar in the callback parameter).
For obvious reasons, the first option is pretty crap and really only useful on platforms where Twitter is unable to redirect to a custom URI.
A simple solution may be to create an HTTP page that always sends a 301 redirect to your custom URL scheme and then provide that HTTP URL to the twitter web API.
Aside from that, Nathan's answer is very complete.
Here's how I do it: tell Twitter you're a web app, and make up any old HTTP:// URL to satisfy Twitter during registration of your oauth client.
Then in your app, pass the URL you want to in the callback parameter. Twitter (in my experience) uses the one you give it.
You could use an intermediate website for the authentication. Your app creates a unique id (hardware based?) and stores it. It then records it has sent the user for authentication and sends the unique id to your website. It then redirects the user to your website. Your website then sends the user to Twitter using oAuth. The user returns to your website and you mark the unique id as authenticated and store the authentication information. The user restarts the app on the iPhone, it reads it has sent the user for authentication and contacts your website with the unique id - and reads in the authentication information.
Long winded and needs another website, but it should work.