I wanted to create a new release of xc_installation project. It is a Drupal distribution, and has a drupal-org.make file. The make file is usually veryfied agains a whitelist. Today when I tried the create a new release package, I received an error message:
The drupal-org.make file for project eXtensible Catalog (XC) Installation Profile failed verification for Git tag 6.x-1.3-rc9.
http://drupal.org/node/642116 -- to learn more about correcting these errors.
Whitelist download from http://drupal.org/packaging-whitelist/json [error]
failed: not found
The drupal.org validation check failed -- see [error]
http://drupal.org/node/1432190 for more information.Once these errors are fixed, commit the changes to your drupal-org.make, move the release tag for your project (check the Git manual to learn how to move tags if necessary), and submit the release node again.
I read all pages which are referred in this error message, and tried to veryfy the make file in local environment with drush verify-makefile
command, and I received this warning message:
http://drupal.org/packaging-whitelist/json): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden. You should know better.
Then I tried to access the file with file_get_content(), and it also failed.
$ php -r "file_get_contents('http://drupal.org/packaging-whitelist/json');"
Warning: file_get_contents(http://drupal.org/packaging-whitelist/json): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden. You should know better.
in Command line code on line 1
Call Stack:
0.0001 646904 1. {main}() Command line code:0
0.0001 647160 2. file_get_contents() Command line code:1
When I hacked drush to use cURL method, the result was the same.
The strangest thing is, that the file is there, I can access it with browser, and with command line curl and wget tools. I guess, that the packaging script use some similar (if not even identical) method to fetch the file as Drush.
Comment | File | Size | Author |
---|---|---|---|
#21 | forbidden-error-temp-fix-1916598-21.patch | 587 bytes | Devin Carlson |
#4 | drupalorg_drush-remote-file-1916598-3.patch | 1.87 KB | klausi |
Comments
Comment #1
artofeclipse CreditAttribution: artofeclipse commentedI'm facing this issue right now, trying to get it working but no luck, I will keep investigating this issue for now.
Comment #2
klausikilles said that there has been a request filter deployed on drupal.org yesterday which blocks requests without User-Agent. Apparently file_get_contents() does not send a User-Agent, so it is blocked.
Do we fix drupalorg_drush to not use file_get_contents() or do we roll back the request filter on drupal.org?
Comment #3
gregglesThe request filter let drupal.org's servers stay online, so I think we keep it and patch drupalorg_drush.
Comment #4
klausiMoving to drupalorg_drush.
This patch tries cURL first and adds a user agent.
I get a lot of phpunit test failures with that, need to check if they pass without it.
Comment #5
klausiRestoring title.
Comment #6
klausiReports 17 failures before and after the patch, so the test cases seem to be broken anyway.
Comment #7
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedSeems good to me. We should let somebody else review it too, and then deploy it asap.
Comment #8
artofeclipse CreditAttribution: artofeclipse commentedpatch #4 worked on my local machine
Comment #9
jsacksick CreditAttribution: jsacksick commentedI just tested the patch against the drupal-org.make file of kickstart and It worked.
drush verify-makefile drupal-org.make
Makefile drupal-org.make passed.
Comment #10
jhedstrom#4 looks good to me. Committed in 69e3e69. I'll leave this at RTBC so somebody can deploy the fix.
Comment #11
drummAs I was deploying this, I noticed our deployment system for this was broken a bit. We have a couple Jenkins jobs for this, started by deploy_packaging_drush_drupal.org. Both had the same script in Jenkins, so I moved it to our infrastructure repo, http://drupalcode.org/project/infrastructure.git/blob/036b8b8:/live/depl.... I added the last line, which actually merges in changes if you are updating a branch. The git_id parameter advertises "Can be either a branch name, tag, or even a specific commit hash." I think I might have broken specific commit hashes.
I'd like to see the whole drupalorg_drush_get_remote_file() function replaced with
drush_download_file()
or something.drupal_http_request()
would be ideal since it loads directly to memory, but this drush command is not invoked on a bootstrapped Drupal install.Comment #12
pkiraly CreditAttribution: pkiraly commentedThank you all! It works again, and I was able to create a new release.
Comment #13
dwwCool, thanks everyone!
Re #11:
See #1401864: more robust download functionality
Cheers,
-Derek
Comment #15
lolandese CreditAttribution: lolandese commentedStill some problems with this. Still a 403 forbidden error on http://drupal.org/packaging-whitelist/json when using
fopen
method.From my terminal:
Using the latest version:
git clone [user]@git.drupal.org:project/drupalorg_drush.git drupalorg_drush
Any hints on what I'm doing wrong?
Thanks.
EDIT:
Solved by enabling cURL, so it takes that method instead of fopen:
sudo apt-get install php5-curl
Maybe something to look into anyway as it fails when cURL is not enabled. No idea if it would fail also using the wget method.
Comment #16
lolandese CreditAttribution: lolandese commentedStill seems to fail if cURL is not enabled. See above.
Thanks.
Comment #17
drummComment #18
dwwI wonder if the problem is http vs. https. The http should redirect to https, but maybe that's not happening for your client. What happens if you try to directly curl https://drupal.org/packaging-whitelist/json instead?
Comment #19
Claire Hernandez CreditAttribution: Claire Hernandez commentedHi,
I got the same problem but the answer does seem working for me. Another idea ?
Thanks.
Comment #20
bart.hanssens CreditAttribution: bart.hanssens commentedSame here, using drush 5.9 on Debian, with php5-curl installed.
Comment #21
Devin Carlson CreditAttribution: Devin Carlson commentedSame issue as #19 and #20 whether I use cURL or
allow_url_fopen()
(only the error message changes).I read Details on Server SSL Certificates and was able to bypass the issue by using cURL and specifying:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE);
although I'm not sure that's a good idea. :P