HTTP Remote Auth

For some reason Android Apps (every one we’ve tested) do not like the HTTP Remote Auth by S2Member. We’ve tested with iTunes and other iPhone apps with success, but Android apps (DoggCatcher, BeyondPod) continue to fail. This is critical that we get this working soon; any thing we might be missing? The fact that we have it running on the Apple side says we got it set up correctly – at least for that platform.

Thanks for the report, Mark.

I’ll ask Jason about this.

Thanks for the heads up on this thread.

@Mark

I just tested an s2Member protected file download with remote authentication using a Motorola Atrix running Android v2.3.6 and it works fine from my end of things. I’m prompted for my username/password and upon entering the proper credentials, the file download begins.

If problems persist on your end, can you please let us know the specifics of what fails during your tests. For instance, does the username/password authentication window not open at all? Or it opens, but fails to authenticate you?

I would try testing in the phone’s browser first. If it works there, but does not work in specific Apps, it could be related to the app itself, which might NOT be capable of dealing with protected content that requires remote authentication to access. Some apps are incapable of sending the “Authorization” header, or dealing with a 401 header in an HTTP response, which is something that browsers ARE capable of.

Hi Jason –

Yes – indeed it will work from within an Android browser – just not any Android App (like DoggCatcher). The one exception is that BeyondPod was able to figure out a workaround. However, going to each and every podcast software developer and get them to add the same workaround is not a good solution.

We can’t just exclude Android users. And we can’t be the only one using HTTP Auth and have Android users. Have you run into this before? Has anyone got S2M + S3 CloudFront to work with Android users?

Thanks much for your time!

Jason –

Here’s a conversion between a BeyondPod developer and a devoted/talented member – it sheds some good light on what is going on behind the scenes.

http://www.beyondpod.com/forum/showthread.php?580-Young-Turks-Issue&p=1809&viewfull=1#post1809

This might leave S2M out of it completely – although the question still remains that others must be having the same issues – since anyone using S2M and S3 to secure podcasts will have the same results with all Android users. Do you have any comments/input on this issue? Is there by chance anything that can be done from the S2M side that might help resolve this issue? It’s worth at least asking. :)

Thanks for the follow-ups here.

So sorry. I don’t have any personal experience with the apps you mentioned. However, here are some general suggestions that might help in some cases, or perhaps spawn new ideas for you.

1. Instead of using Remote Authentication (i.e. HTTP header authorization); you could provide your members with links to download files, which include a File Download Key in the link itself (which provides the authentication). This will avoid the need to use Remote Authentication in most cases. While it’s not always practical to go this route, in many cases it does fit the bill. You can learn more about this from your Dashboard.

See: Dashboard -› s2Member® -› Download Options -› Advanced Download Restrictions

For instance, if you have the ability to generate a podcast feed dynamically (i.e. with PHP), you could build links that include File Download Keys for each MP3 file that will be available in your feed.

2. Some apps (like iTunes as one example), will be capable of working around potential issues with HTTP authentication, if you place your XML feed file itself, inside a location that requires HTTP authentication. In other words, make your XML feed manually, and then place it inside of the /s2member-files/ directory. Provide users with a File Download link for the XML feed, which requires Remote Authentication (i.e. HTTP Authentication). In this way, if the feed itself requires HTTP authentication, the client application might be able to handle HTTP authentication on the feed, and then NOT need to handle it for each MP3 file available within the feed. It just depends on the app though.

See also, this video: Video » s2Member® File Downloads (Remote Auth/Podcasting)

3. Another possibility is to build a mobile app of your own. A custom app might be built in a way that interacts with s2Member’s ability to produce File Download Keys, as I mentioned in #1 above.