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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jobeirne’s picture

This situation can be remedied with the use of an Apache rewrite and a patch to the underlying OAuth library.

In .htaccess:

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
  RewriteCond %{REQUEST_FILENAME} !-f 
  RewriteCond %{REQUEST_FILENAME} !-d 
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^ index.php [L] 

  # Pass Authorization headers to an environment variable
  RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
</IfModule>

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.

jobeirne’s picture

On further inspection of OAuth.php, there's a way more simple solution that just involves the rewrite; no patch needed:

<IfModule mod_rewrite.c>
  RewriteEngine on

  # Pass all requests not referring directly to files in the filesystem to
  # index.php. Clean URLs are handled in drupal_environment_initialize().
  RewriteCond %{REQUEST_FILENAME} !-f 
  RewriteCond %{REQUEST_FILENAME} !-d 
  RewriteCond %{REQUEST_URI} !=/favicon.ico
  RewriteRule ^ index.php [L] 

  # Pass Authorization headers to an environment variable
  RewriteRule .* - [E=HTTP_Authorization:%{HTTP:Authorization}]
</IfModule>
kotnik’s picture

If you sport Apache with Fcgi you can add this to virtual host definition:

    FcgidPassHeader AUTHORIZATION
ksenzee’s picture

Version: 7.x-3.0-alpha2 » 7.x-3.x-dev
Priority: Major » Normal
Status: Active » Needs review
FileSize
382 bytes

I 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.

juampynr’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

g10’s picture

Status: Closed (fixed) » Needs work

This 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:

      if (isset($out['Auth'])) {
        $out['Authorization'] = $out['Auth'];
      }
juampynr’s picture

@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.

Nick_vh’s picture

Status: Needs work » Needs review
FileSize
360 bytes

here's a patch for this. Loads of notices indeed :)

cloudbull’s picture

Hi 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

everright’s picture

FileSize
1.01 KB

It'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

server {
    listen       80;
    server_name  www.drupal7.local;
    access_log  logs/drupal7.local.access.log  main;
    root   /Working/Websites/drupal7.local/;
    index  index.php;

    location / {
        try_files $uri $uri/ @drupal;
    }
    location @drupal {
        rewrite ^/(.*)$ /index.php?q=$1 last;
    }
    error_page 404 /index.php;
    location ~ .php$ {
        fastcgi_pass   127.0.0.1:5322; #replace with your port
        fastcgi_index  index.php;
        fastcgi_param REDIRECT_URL $request_uri; #add this parameter
        include fastcgi.conf;
    }
    # protection for sensitive info
    location ~ (/\..*|settings\.php$|\.(htaccess|engine|inc|info|install|module|profile|pl|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(Entries.*|Repository|Root|Tag|Template))$ {
        deny all;
    }
    # turn off access logs for stylesheets and scripts
    location ~ \.(css\js)$ {
        access_log off;
    }
    # performance for images
    location ~* \.(jpg|jpeg|png|gif|ico)$ {
        expires 45d;
        access_log off;
    }
    # deny access to .htaccess files, if Apache's document root
    location ~ /\.ht {
        deny  all;
    }
}
Pancho’s picture

Status: Needs review » Closed (fixed)

Created a new issue for the patch in #9, see: #1976504: Notice: Undefined index: Auth in OAuthUtil::get_headers()
Closing this issue here again.

Pancho’s picture

Issue summary: View changes

grammar

zhouhana’s picture

Issue summary: View changes

I 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:

$ patch -p1 < 1365168-4.fastcgi-fix.patch
patching file lib/OAuth.php
Hunk #1 succeeded at 846 with fuzz 2 (offset 17 lines).

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?

jojonaloha’s picture

@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.

zhouhana’s picture

Thanks for the clarification!