Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.10.14

Bug #11642 PEAR fails to authenticate when downloading deps from non-default channels
Submitted: 2007-07-19 11:13 UTC
From: timj Assigned: timj
Status: Closed Package: PEAR (version 1.6.1)
PHP Version: 5.1.6 OS:
Roadmaps: 1.6.2    

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 35 + 36 = ?

 [2007-07-19 11:13 UTC] timj (Tim Jackson)
Description: ------------ PEAR forgets to use the configured HTTP authentication details for a channel when downloading dependencies, under certain circumstances. I am still trying to see if I can find any more specific details but the basic problem seems to be related to whether you are installing a package directly or implicitly as the result of a dependency. I can reliably reproduce this. For example: $pear install package.xml (for some random app, requires package Foo directly) ... Could not download from "http://mychannel/get/Foo-1.0.0.tgz", cannot download "mychan/Foo" (File http://mychannel:80/get/Foo-1.0.0.tgz not valid (received: HTTP/1.0 401 Unauthorized)) Error: cannot download "mychan/Foo" Download failed install failed Follow this immediately by: $ pear install mychan/Foo downloading Foo-1.0.0.tgz ... Starting to download Foo-1.0.0.tgz (6,608 bytes) .....done: 6,608 bytes install ok: channel://mychannel/Foo-1.0.0 ! A check of the web server logs on the channel server shows that PEAR is indeed authenticating (correctly) in the latter case but not in the former.


 [2007-07-19 12:07 UTC] timj (Tim Jackson)
This happens because line 1636&1637 of PEAR/Downloader.php fail to specify a channel when they retrieve the username and password, meaning that if the channel from which a package is being downloaded is not the default channel, its HTTP authentication details will not be picked up.
 [2007-07-19 12:09 UTC] timj (Tim Jackson)
The patch I just attached fixes this problem for me.
 [2007-08-18 22:09 UTC] cellog (Greg Beaver)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.
 [2007-12-11 01:22 UTC] timj (Tim Jackson)
PEAR 1.6.2 *generally* seems fixed but today I've seen this exact same bug crop up again on a 1.6.2 installation, for reasons I can't immediately fathom. Perhaps there's a case we missed?
 [2007-12-11 01:37 UTC] timj (Tim Jackson)
I still can't quite put my finger on what causes this to happen sometimes but not others, but I think the call to downloadHttp() in line 88 of PEAR/REST.php needs to pass the channel info through. This of course means modifications in the various functions that call it, which in turn means passing around channel info to functions like PEAR_REST_XX::listAll() etc. This seems logical but am I missing something?