Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We need to proxy pass an url in which my.domain.com need to get drupal.apps.server.com. We configured rewrite and is working fine.

Then we configured proxypass and while accessing my.domain.com we are getting the contents but we are unable to login to application (Drupal admin page). If you are accessing directly through drupal.apps.server.com we are able to login and access the admin page.

Please see our configuration :

server {
        listen   80;
        server_name my.domain.com;
                location /{
                proxy_pass http://drupal.get apps.server.com/;
                proxy_set_header X-Forwarded-Host $host;
                proxy_set_header X-Forwarded-Server $host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                }
       }

Can anyone please help us on it.

Thanks Geo

share|improve this question

2 Answers 2

Your syntax looks correct for accessing your Drupal site through http://my.domain.com/ I am using the same kind of syntax for proxying with Nginx myself. I suspect the issue is elsewhere.

It may a cookie issue. Make sure your Drupal configuration is updated so that it believes my.domain.com is the address of the Drupal installation.

If that's not the issue, you should clarify the following:

  • When you say "can't login", exactly how far do you get, and what is returned to the screen?
  • What do you find in your access and error logs when you can't login

Also, use a tool to inspect the HTTP request and response headers that they are in order. (You could double check the cookie domains, for example). My favorites are the 'HEAD', 'POST' and 'GET' tools from Perl's LWP::UserAgent distribution. (libwww-perl on some Linux distributions). For example:

POST -sSe http://my.domain.com/drupal/login/form

UPDATE You've clarified that links from the home page reveal the backend URLS. Make sure your URLS are either relative, or absolute URLs to 'http://my.domain.com'. If the URLs point directly to the backend server, they won't work.

share|improve this answer
    
Our drupal is already configured to use my.domain.com as the address. But we are getting the same issue. In addition to drupal we are using another application called activecollab configured as same but for this application too we able to access but unable to login. So it seems an nginx proxy issue. Thanks –  Geo Aug 1 '12 at 11:10
    
My answer has been updated with further suggestions. –  Mark Stosberg Aug 1 '12 at 12:40
    
Dear Mark Thanks for your update. Actually this is our latest update..... While accessing my.domain.com we are getting the home page and then if you click any url that goes to a subfolder (for eg: my.domain.com/reg) then we are getting the url as anyapp.apps.server.com/reg. Please let me know your update. Is there any issue with current configuration... Our scenario is as follows: We need to access anyapp.apps.server.com and all subfolder (anyapp.apps.server.com/*) through my.domain.com please let me know any sample configuration to accomplish this. Thanks –  Geo Aug 1 '12 at 13:18
    
I've updated my answer to clarify that your syntax looks correct, and the problem is most likely elsewhere. See my 'UPDATE' clause about reviewing your links. Also, you have not responded about what you see in your logs. –  Mark Stosberg Aug 1 '12 at 13:33

I had the same kind of setup running on Fedora 14 using this nginx config:

location / {
    proxy_pass      http://internal-server.example.com:8064;
    proxy_set_header HTTP_USING_HTTPS 1;
    proxy_set_header X_FORWARDED_HOST example.com;
}

Then I upgraded to Fedora 17 and began to see the same behaviour. The username/password was accepted, but I received an error from Drupal telling me I did not have access.

I looked into it by using Firebug and saw this HTTP-header when logging in:

Set-Cookie SESSb13(skipped)706445be1=dg_xv(skipped)ZI; expires=Fri, 21-Sep-2012 21:40:17 GMT; path=/; domain=.internal-server.example.com; HttpOnly

This led me to think there was a problem with the cookie domain.

I am not entirely sure this is caused by running an updated version of Nginx, but adding the following "proxy_set_header" line to the Nginx configuration solved the problem for me:

location / {
    # The next line solved the problem for me:
    proxy_set_header Host $http_host;

    proxy_pass      http://internal-server.example.com:8064;
    proxy_set_header HTTP_USING_HTTPS 1;
    proxy_set_header X_FORWARDED_HOST example.com;
}

So maybe there was a change in the default behaviour of proxy_pass. Anyway, I hope it may help others.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.