Can't authorize consumers when running under FastCGI

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

    FcgidPassHeader AUTHORIZATION

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.

Committed 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

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'];
      }

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

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

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

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;
    }
}

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

grammar

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?

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

Thanks for the clarification!