I all!

I spend a few days trying to make it work on ningx :/

I had an issue, because includes/DrupalOAuthRequest.inc at from_request funcion check the REDIRECT_URL var, which is an apache var, so it is not available in nginx.

To fix that I added a new line at nginx.conf:

location ~ \.php$ {
include /opt/nginx/conf/fastcgi.conf;
fastcgi_index index.php;
fastcgi_pass unix:/tmp/php-fpm.sock;
fastcgi_param REDIRECT_URL $request_uri; #This solve all my problems :D.

Hope it helps, I spend days figuring it out hehehe.



kobee’s picture

Nice try, but the REDIRECT_URL variable is NOT the same as request_uri ..

On Apache, REDIRECT_URL return the request_uri without the "?parameters" at the end..

ruloweb’s picture

Good! and do you know which is the correct one?

Anyway, it works with request_uri :P


kobee’s picture

Not really, but I found an other way by the $_REQUEST[q] to get the path without any other parameter (added by twitter or email campaign, etc ... :-()


juampynr’s picture

Should we update documentation? Is there a PHP way what is compatible for both web servers?

windm’s picture

Hi there,

is there any change or progress on the nginx issue? To be honest, I can´t judge on if the solution above is something final or maybe not the right way... Have you made any patches related to this issue?
And if so... how could I patch the OAuth for d6 to make it work on a nginx Server?

drupdan3’s picture

Generally speaking, the way to be compatible not with "both" but with ALL servers is not to blindly use Apache-only extensions because "everybody's on Apache". Similarly for using MySQL-isms.

REDIRECT_URL is only set when an internal redirect happens within Apache. Unless you need to figure out what happened deep within Apache's brains prior to "getting here", one can just use $_SERVER['REQUEST_URI']. See for example:


Now, looking at the code in oauth-7.x-3.0 I see that REDIRECT_URL is only used

      // Unset $_GET['q'] if it was created by a redirect
      if (isset($_SERVER['REDIRECT_URL'])) {
        $q = FALSE;

and I don't see how that can hurt (or how ALWAYS setting REDIRECT_URL could help).

chustedde’s picture

Issue summary: View changes

We are successfully using the OAuth module on Pantheon (which is on nginx) with the following added to our settings.php:

// Modify server variables to be compatible with the OAuth.php library
if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == "on") {
else {
$_SERVER['QUERY_STRING'] = preg_replace("/&{0,1}q=[^&]*&{0,1}/i", "", $_SERVER['QUERY_STRING']);

Since it's hosted on Pantheon, we haven't touched any of the nginx configuration, and the only change we made to the module itself was applying this patch: #922110: user/login destination parameter incorrectly including base directory on authorize page

kekko1’s picture

work for me on nginx.
no other changes....


Chalk’s picture

#7 solves an issue of an error "Invalid signature" at the Pantheon.

joelrotelli’s picture

#7 Save my life too ! Thanks !!