Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When Drupal is running under certain FastCGI web servers, e.g. those used at Acquia, Authentication headers are stripped from HTTP requests before they hit Drupal. Thus, attempts to authenticate Consumers with valid secrets and keys result in 401 errors.
N.B.: this is not a bug with the OAuth module, per se, but the use of this module with FastCGI does result in the pretty-baffling situation described above.
Comment | File | Size | Author |
---|---|---|---|
#11 | fastcgi.conf_.txt | 1.01 KB | everright |
#9 | 1365168-9.patch | 360 bytes | Nick_vh |
#4 | 1365168-4.fastcgi-fix.patch | 382 bytes | ksenzee |
#1 | fast_cgi_rewrite-1365168-1.patch | 1.5 KB | jobeirne |
Comments
Comment #1
jobeirne CreditAttribution: jobeirne commentedThis situation can be remedied with the use of an Apache rewrite and a patch to the underlying OAuth library.
In .htaccess:
Applying the included patch tells OAuth to look in $_SERVER['HTTP_AUTHORIZATION'] for the authentication information it'd normally pull from the HTTP header.
I'll be passing on the included patch to the OAuth library that this module uses, but it is included here for convenience.
Comment #2
jobeirne CreditAttribution: jobeirne commentedOn further inspection of OAuth.php, there's a way more simple solution that just involves the rewrite; no patch needed:
Comment #3
kotnik CreditAttribution: kotnik commentedIf you sport Apache with Fcgi you can add this to virtual host definition:
Comment #4
ksenzeeI ran into this as well, and it seems to me the simplest way to handle it is to make a small fix to the underlying oAuth library (https://github.com/juampy72/OAuth-PHP/pull/1). I'm attaching a patch that applies the fix to the 7.x-3.x branch as well.
Comment #5
juampynr CreditAttribution: juampynr commentedCommitted to 7.x-3.x, 6.x-3.x and Github. Many thanks.
http://drupalcode.org/project/oauth.git/commitdiff/93c71f5
http://drupalcode.org/project/oauth.git/commitdiff/1d4df51
https://github.com/juampy72/OAuth-PHP/pull/1
Comment #7
g10 CreditAttribution: g10 commentedThis patch litters the logs with following notice:
Notice: Undefined index: Auth in OAuthUtil::get_headers() (line 844 of /var/www/vhosts/api.foodpairing.com/httpdocs/sites/all/modules/contrib/oauth/lib/OAuth.php).
isset() resolves this:
Comment #8
juampynr CreditAttribution: juampynr commented@g10, could you please close this issue again and open a new one with a patch. I would happily test it and give you authorship if committed.
Comment #9
Nick_vhhere's a patch for this. Loads of notices indeed :)
Comment #10
cloudbull CreditAttribution: cloudbull commentedHi Nick_vh,
Will your patch works on Nginx ? My configuration with Nginx, oauth-7.x-3.x-dev , still no luck to login.
Please kindly advice
Keith
Comment #11
everright CreditAttribution: everright commentedIt's worked for me with no patchs.
My test environment:
Nginx + PHP-FPM
Nginx: [1.2.7]
PHP: [5.3.22]
Drupal [7.21]
OAuth [7.x-3.1]
OAuth Login Provider [7.x-1.1]
Services [7.x-3.3]
Libraries [7.x-2.1]
CTools [7.x-1.2]
Nginx vhost
Comment #12
PanchoCreated a new issue for the patch in #9, see: #1976504: Notice: Undefined index: Auth in OAuthUtil::get_headers()
Closing this issue here again.
Comment #12.0
Panchogrammar
Comment #13
zhouhana CreditAttribution: zhouhana as a volunteer commentedI can't read PHP very well myself, so I just want to double check. Because of the recent security release to OAuth I'm trying to update the module for a few sites, and now I'd like to reapply the patches that were previously applied, so the sites don't lose any important functionality.
The release notes for OAuth say nothing about this patch being included in the non-dev branch. When I try to apply it through the command line I get this:
Does this mean the patch was applied as intended? I'm thinking that since the patch is so old maybe there's some kind of mismatch between it and the code that is now in 7.x-3.3 that would need to be reviewed?
Comment #14
jojonaloha CreditAttribution: jojonaloha at Metal Toad commented@zhouhana you shouldn't need to apply the patch in #4 of this issue if you've updated, as the change has already been committed (in #5, which was September 9, 2012; so this change should have been in every release since 7.x-3.1)
I tested applying the patch after updating and it results in the same message you got, and the change shows up twice in the code. In this case I think applying it a second time will have no effect, but doing that with other patches could cause problems.
Comment #15
zhouhana CreditAttribution: zhouhana as a volunteer commentedThanks for the clarification!