Using HTTPAuth I configured the following to require HTTP Auth.

blog/*
system/files/*

I then created some blog entries and attached an .mp3 file to each using upload module (set to private).

I get the expected auth prompt when I try to go to say blog/1/feed from the browser and I could also get the feed with wget with the proper username and password and 401 when sending no username or password.

I could not get this to work with iTunes which should support basic authentication and also digest authentication when I subscribed to ?q=blog/1/feed which has the two items with enclosures.

Comments

decafdennis’s picture

decafdennis commented
Title: HTTPAuth does not seem to work with iTunes for password projected podcasts » HTTP authentication does not seem to work with iTunes

Thanks!

decafdennis’s picture

decafdennis commented
Assigned: Unassigned » decafdennis
decafdennis’s picture

decafdennis commented

Do you have "Only allow a session id to be propagated using URL parameters if HTTP authentication was used." enabled? Try disabling it, it doesn't seem to work correctly.

Note: I haven't tested with iTunes yet.

dldege’s picture

dldege commented

I don't see such a setting - where is that at?

decafdennis’s picture

decafdennis commented

If you don't see it on administer > settings > httpauth, then never mind. In your case there probably is a notice in place of the checkbox.

decafdennis’s picture

decafdennis commented

I tested with iTunes and although I wasn't able to get enclosures working ("There are no playable episodes"), I did get authentication to work. You just need to change the appropriate settings.php file in the settings folder, just like the notice on admin/settings/httpauth says. Change:

ini_set('session.use_only_cookies', 1);

to

ini_set('session.use_only_cookies', 0);

iTunes doesn't support cookies. Changing this setting allows the PHP session id to be propagated through the URL instead of cookies. This might introduce a security threat, and this is why there is the "Only allow a session id to be propagated using URL parameters if HTTP authentication was used." checkbox.

Please tell me if the module works for you now.

decafdennis’s picture

decafdennis commented
Category: bug » support
dldege’s picture

dldege commented

Thanks for testing this. If I change the ini setting is that only for http auth or are cookies completely disabled? Did you try basic, digest, or both? I'll test it as soon as I get a chance - thank you.

I can shed some light on your enclosure problem. iTunes will filter out any enclosures that are not media types is supports (mp3, aac, m4v, etc.). Unfortunately is does this using the extension of the enclosure url and not by checking the mimetype attribute (pretty stupid). So if your enclosure urls are to a php or other active server page it will not add them in as enclosures when you subscribe to the podcast in iTunes. You either have to return real urls with proper extensions or there is support for temporary redirects but it still requires returning your url with a proper extension (pretty stupid). http://www.voxmedia.org/wiki/ITunes_Tips#iTunes_Issues

Again, thanks for the great work on this module.

decafdennis’s picture

decafdennis commented

Try the latest development version of httpauth and tell me if it works for you now. The ini change shouldn't be necessary anymore. Sorry, should've posted this here earlier.

For your info, that ini setting does not disable cookies, but it additionally enables the session id to be passed using the query string. E.g. http://example.com/?PHPSESSID= This is potential security hazard, which is why I had added the option to disallow the session id to be passed when not using http authentication.

Aha, I did upload mp3 files but I was using private downloads, which is why iTunes didn't recognize the URLs.

dldege’s picture

dldege commented

I've moved over to 5.0 - are these changes in the DRUPAL-5 branch?

Thx.

decafdennis’s picture

decafdennis commented
Version: 4.7.x-1.x-dev » 5.x-1.x-dev

Yes, they are.

dldege’s picture

dldege commented

Looks like it worked - very cool.

I still am unable to logout though. Also, are you still planning to add digest mode auth?

Thanks.

decafdennis’s picture

decafdennis commented

Regarding the logout issue, I'm working on it. See #97931. Personally I don't see it as such a big problem, because usually you don't use httpauth to authenticate in your browser... maybe you can give me a case where it is a problem?

Digest authentication is not possible with Drupal. I'd need the clear text password, but (luckily) only hashes (checksums) are saved to the database. See #97658.

dldege’s picture

dldege commented

Thanks for the update on digest mode - I forgot that the md5 hash of the password only is saved.

Regarding logout - a simple scenario is that you httpauth protect a blog/podcast then if you are reading that blog in a feed reader (not the browser) and click the link to the article you will get the httpauth challenge from the browser instead of the drupal login. You are now unable to log out from the drupal site. Maybe not a big deal at home but at a work computer or other public computer that would not be a good thing.

What is the actual issue that prevents the logout - I don't really understand what the mechanics are for this? Clearing cookies, etc. doesn't seem to have any effect on the problem.

Thx.

decafdennis’s picture

decafdennis commented

It's that most browsers remember the authentication credentials at least until you completely quit out of it. I'll try and come up with a solution.

decafdennis’s picture

decafdennis commented
Status: Active » Fixed
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)