Hello, I'm trying to replace apache2 by nginx. So far my platform debian squeeze + Apache2 + sogo 2.0.2 works very fine. However I decided to replace apache2 by nginx 1.2.4-1. It works too but it seems there is a redirection that doesn't work. My url : https://sogo.mydomain give a page error 403 forbidden. I have to complete the url with /SOGo so that I get the login. Here is the error.log of nginx : directory index of "/usr/lib/GNUstep/SOGo/WebServerResources/" is forbidden, client: 90.2.225.249, server: sogo.mydomain, request: "GET / HTTP/1.1", host: "sogo.mydomain" Here is my sogo.conf : --------------------------------- server { listen 443; server_name sogo.ias.u-psud.fr; root /usr/lib/GNUstep/SOGo/WebServerResources/; ssl on; ssl_certificate /etc/nginx/ssl.fac/wildcard.ias.u-psud.fr.crt; ssl_certificate_key /etc/nginx/ssl.fac/wildcard.ias.u-psud.fr.key; location ^~/SOGo { proxy_pass http://127.0.0.1:20000; proxy_redirect http://127.0.0.1:20000 default; # forward user's IP address proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_set_header x-webobjects-server-protocol HTTP/1.0; proxy_set_header x-webobjects-remote-host 127.0.0.1; proxy_set_header x-webobjects-server-name $server_name; #proxy_set_header x-webobjects-server-url https://sogo.ias.u-psud.fr; proxy_set_header x-webobjects-server-url $scheme://$host; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; client_max_body_size 50m; client_body_buffer_size 128k; break; } location /SOGo.woa/WebServerResources/ { alias /usr/lib/GNUstep/SOGo/WebServerResources/; allow all; } location /SOGo/WebServerResources/ { alias /usr/lib/GNUstep/SOGo/WebServerResources/; allow all; } location ^/SOGo/so/ControlPanel/Products/([^/]*)/Resources/(.*)$ { alias /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2; } location ^/SOGo/so/ControlPanel/Products/[^/]*UI/Resources/.*\.(jpg|png|gif|css|js)$ { alias /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2; } } ------------------------------ I would be very pleased to get some advices. Best regards. Gerard Breiner Posted at Nginx Forum: http://forum.nginx.org/read.php?2,232325,232325#msg-232325
on 2012-10-29 14:58
on 2012-10-29 21:58
On Mon, Oct 29, 2012 at 09:57:54AM -0400, gerard breiner wrote: Hi there, > It works too but it seems there is a redirection that doesn't work. My url : > https://sogo.mydomain give a page error 403 forbidden. I have to complete > the url with /SOGo so that I get the login. If you don't tell nginx about the redirection you want, you can't expect it to work. You have five locations defined: > location ^~/SOGo { > location /SOGo.woa/WebServerResources/ { > location /SOGo/WebServerResources/ { > location ^/SOGo/so/ControlPanel/Products/([^/]*)/Resources/(.*)$ { > location ^/SOGo/so/ControlPanel/Products/[^/]*UI/Resources/.*\.(jpg|png|gif|css|js)$ The rules are at http://nginx.org/r/location The last two above are unlikely to do what you expect. The initial request is for "/". That doesn't match any of your locations, and so will use the "default" server-level one. Probably what you want is something like location = / { return 301 /SOGo/; } but you may prefer to use a full url, starting "http". f -- Francis Daly francis@daoine.org
on 2012-10-30 16:11
Hello Francis,
I replaced :
location ^~/SOGo {
proxy_pass http://127.0.0.1:20000;
proxy_redirect http://127.0.0.1:20000 default;
By
location /SOGo {
proxy_pass http://127.0.0.1:20000/;
}
And I get the URL I expected https://sogo.mydomain/SOGo but when I want
authenticate to I get the message :
"You can not authenticate because the witnesses (cookies) on your
browser is
disabled. Enable cookies in your web browser and try again."
How to configure this in nginx ? I tried to add "add_header Set-Cookie
lcid=1033;" without success.
Best regards
Gerard
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,232325,232391#msg-232391
on 2012-10-30 18:16
On 30 October 2012 15:11, gerard breiner <nginx-forum@nginx.us> wrote: > I get the message : > > "You can not authenticate because the witnesses (cookies) on your browser is > disabled. Enable cookies in your web browser and try again." > > How to configure this in nginx ? I tried to add "add_header Set-Cookie > lcid=1033;" without success. Nginx doesn't touch cookies unless you explicitly tell it to. Perhaps you have them disabled in your browser. Jonathan -- Jonathan Matthews // Oxford, London, UK http://www.jpluscplusm.com/contact.html
on 2012-10-30 20:38
On Tue, Oct 30, 2012 at 11:11:31AM -0400, gerard breiner wrote: Hi there, > } I don't think that that is what I suggested. How does that help "GET /" become "GET /SOGo"? > And I get the URL I expected https://sogo.mydomain/SOGo but when I want > authenticate to I get the message : > > "You can not authenticate because the witnesses (cookies) on your browser is > disabled. Enable cookies in your web browser and try again." If I was trying to fix this, I would try to learn what the expected http request/response sequence was; and then see what the actual http request/response sequence is; and then compare the two. So: starting from the nginx machine, what "curl -i" query or queries should you use to do a login? (Possibly the logs of the sogo server will tell you.) What happens when you make those queries of (a) the sogo server; and (b) the nginx server? What is different? Specifically, are there Set-Cookie lines that refer to the sogo internal hostname that should really refer to the nginx external hostname? Good luck with it, f -- Francis Daly francis@daoine.org
on 2012-10-31 12:03
Hello, curl -k -i https://127.0.0.1 as curl -k -i https://sogo.mydomain.fr give: ------------------------------ HTTP/1.1 302 Found Server: nginx/0.7.67 Date: Wed, 31 Oct 2012 10:37:27 GMT Content-Type: text/plain; charset=utf-8 Connection: keep-alive content-length: 0 location: /SOGo/ -------------------------------- From sogo.log Oct 31 11:44:05 sogod [29392]: SOGoRootPage successful login for user 'gbreiner' - expire = -1 grace = -1 [31/Oct/2012:11:44:05 GMT] "POST /SOGoSOGoSOGo/connect HTTP/1.0" 200 27/62 0.016 - - 4K I think the "POST /SOGoSOGoSOGo/" is wrong ... (it is not the navigator because under apache2 it works very fine). Thanks. Best regards Gerard Posted at Nginx Forum: http://forum.nginx.org/read.php?2,232325,232424#msg-232424
on 2012-11-01 00:49
On Wed, Oct 31, 2012 at 07:02:55AM -0400, gerard breiner wrote: Hi there, > -------------------------------- So it redirects to /SOGo/. What happens when you do that manually? curl -k -i https://127.0.0.1/SOGo/ Probably it will redirect again, or else return some html. What you probably want to do is to manually step through the full login sequence until you see the specific problem. Then you can concentrate on that one request. (Also: that doesn't look like nginx 1.2.4. Are you sure that your test system is exactly what you expect it to be?) > From sogo.log > Oct 31 11:44:05 sogod [29392]: SOGoRootPage successful login for user > 'gbreiner' - expire = -1 grace = -1 This is from a later time. So some other requests were involved here. > [31/Oct/2012:11:44:05 GMT] "POST /SOGoSOGoSOGo/connect HTTP/1.0" 200 27/62 > 0.016 - - 4K > > I think the "POST /SOGoSOGoSOGo/" is wrong ... Can you see where that request came from? Probably it was the "action" of a html form within the response of a previous request. Maybe that will help show why SOGo is repeated here. (That said, the HTTP 200 response suggests that the web server was happy with the request.) > (it is not the navigator because under apache2 it works very fine). Searching the web for "sogo and nginx" returns articles from people who claim to have it working. I suggest you step back and do exactly one thing at a time. With your original "location ^~ /SOGo" block, did it all work apart from the initial redirect? If not, fix that first. The SOGo installation guide mentions an apache config file, and says "The default configuration will use mod_proxy and mod_headers to relay requests to the sogod parent process. This is suitable for small to medium deployments.". That suggests that your proxy_pass, proxy_redirect, and proxy_set_header directives may be enough. Good luck with it, f -- Francis Daly francis@daoine.org
on 2012-11-02 22:50
Hello Francis, Francis Daly Wrote: ------------------------------------------------------- > > Content-Type: text/plain; charset=utf-8 > > Connection: keep-alive > > content-length: 0 > > location: /SOGo/ > > -------------------------------- > > So it redirects to /SOGo/. What happens when you do that manually? > > curl -k -i https://127.0.0.1/SOGo/ curl -k -i https://127.0.0.1/SOGo/ give : ----------------------------------------------------- HTTP/1.1 200 OK Server: nginx/1.2.4 Date: Fri, 02 Nov 2012 21:09:16 GMT Content-Type: text/html; charset=utf-8 Content-Length: 2613 Connection: keep-alive <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en"> <head> <title> WEBMAIL I.A.S. </title> <meta content="0" name="hideFrame" /> <meta content="SOGo Web Interface" name="description" /> <meta content="SKYRIX Software AG/Inverse inc." name="author" /> <meta content="stop" name="robots" /> <meta content="@shiva 201210251146" name="build" /> <link href="mailto:support@inverse.ca" rev="made" /> <link rel="shortcut icon" type="image/x-icon" href="https://sogo.mydomain/SOGo/WebServerResources/favi... /> <link rel="stylesheet" type="text/css" href="/SOGo.woa/WebServerResources/generic.css?lm=1351533524" /> <link rel="stylesheet" type="text/css" href="/SOGo.woa/WebServerResources/dtree.css?lm=1351283692" /> <link rel="stylesheet" type="text/css" href="/SOGo.woa/WebServerResources/SOGoRootPage.css?lm=1351611309" /> <!--[if IE]><link rel="stylesheet" type="text/css" href="/SOGo.woa/WebServerResources/iefixes.css?lm=1351283692" /><![endif]--> </head> <body class="popup"> <div id="loginScreen"> <table> <tr> <td> <img src="/SOGo.woa/WebServerResources/sogo-logo.png?lm=1351283693" id="splash" alt="*" /> </td> <td id="loginCell" width="250"> <p>We've detected that your browser version is currently not supported on this site. Our recommendation is to use Firefox. Click on the link below to download the most current version of this browser.</p> <p class="browser"><a href="http://www.getfirefox.com/">Download Firefox</a> <img src="/SOGoSOGo.woa/WebServerResources/browser_firefox.gif?lm=1351283693" alt="*" /></p> <p>Alternatively, you can also use the following compatible browsers</p> <p class="browser"><a href="http://www.google.com/chrome/">Download Chrome</a> <img src="/SOGoSOGo.woa/WebServerResources/browser_chrome.gif?lm=1351283692" alt="*" /></p> <p class="browser"><a href="http://www.apple.com/safari/download/">Download Safari</a> <img src="/SOGoSOGo.woa/WebServerResources/browser_safari.gif?lm=1351283692" alt="*" valign="middle" /></p> </td> </tr> </table> </div> <noscript> <div class="javascriptPopupBackground"> </div> <div class="javascriptMessagePseudoWindow noJavascriptErrorMessage"> SOGo requires Javascript to run. Please make sure this option is available and activated within your browser preferences.<br /><br /><a href="" class="button">Retry</a> </div> </noscript> </body> </html> -------------------------------------------------------------------------------------- > > Probably it will redirect again, or else return some html. What you > probably want to do is to manually step through the full login > sequence > until you see the specific problem. Then you can concentrate on that > one request. > > (Also: that doesn't look like nginx 1.2.4. Are you sure that your test > system is exactly what you expect it to be?) I had downgrade nginx cause I wanted to see if I met the same issue with both versions. I've upgrade it to 1.2.4.... > > 0.016 - - 4K > > > > I think the "POST /SOGoSOGoSOGo/" is wrong ... > > Can you see where that request came from? Probably it was the "action" > of a html form within the response of a previous request. Maybe that > will help show why SOGo is repeated here. Before login there is GET /SOGoSOGo After login there is POST /SOGoSOGoSOGo/ > > I suggest you step back and do exactly one thing at a time. With your > original "location ^~ /SOGo" block, did it all work apart from the > initial redirect? If not, fix that first. > > The SOGo installation guide mentions an apache config file, and says > "The default configuration will use mod_proxy and mod_headers to relay > requests to the sogod parent process. This is suitable for small to > medium deployments.". > Make me puzzle ... For instance , templates will not be loaded without this : location /SOGo.woa/WebServerResources/ { alias /usr/lib/GNUstep/SOGo/WebServerResources/; } > That suggests that your proxy_pass, proxy_redirect, and > proxy_set_header > directives may be enough. > > Good luck with it, > > f > -- > Francis Daly francis@daoine.org > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx I 'm going to get a look at internet for getting a sogo configuration file for nginx. Yet my configuration come from internet and as it didn't work I tried this and that and this and passed too much time working on this issue. If I managed to get it work I'll come back here for sharing. Thank you indeed Francis for your time and the quality of yours answers. Best regards. Gerard Posted at Nginx Forum: http://forum.nginx.org/read.php?2,232325,232465#msg-232465
on 2012-11-03 11:22
On Fri, Nov 02, 2012 at 05:50:08PM -0400, gerard breiner wrote: > Francis Daly Wrote: > ------------------------------------------------------- > > On Wed, Oct 31, 2012 at 07:02:55AM -0400, gerard breiner wrote: Hi there, > Content-Type: text/html; charset=utf-8 > Content-Length: 2613 > Connection: keep-alive <snip> > <link rel="shortcut icon" type="image/x-icon" > href="https://sogo.mydomain/SOGo/WebServerResources/favi... /> So: sogo has been configured with its name, and doesn't just use the Host: header it receives. > <link rel="stylesheet" type="text/css" > href="/SOGo.woa/WebServerResources/generic.css?lm=1351533524" /> And sometimes it uses /SOGo/, and sometimes /SOGO.woa/. From this limited sample, ".woa" includes ?lm=NNN on the end of the url. > <p>We've detected that your browser version is currently not supported on > this site. Our recommendation is to use Firefox. Click on the link below to > download the most current version of this browser.</p> And it does browser sniffing. You can try curl -k -i -A 'Mozilla/5' https://127.0.0.1/SOGo/ to see if you can get at the actual content that your browser gets; or when you just use your browser, you can try to "view page source". The aim is to find why and where the problem arises. But: it turns out that that probably isn't necessary here: > <p class="browser"><a href="http://www.getfirefox.com/">Download > Firefox</a> <img > src="/SOGoSOGo.woa/WebServerResources/browser_firefox.gif?lm=1351283693" > alt="*" /></p> /SOGoSOGo.woa/ appears in there. So it looks like even this page shows a problem. What do you see here when you go direct to sogo? curl -k -i https://127.0.0.1:20000/SOGo/ Does it have /SOGoSOGo in it? What do you get for the following: curl -k -I https://127.0.0.1/SOGoSOGo.woa/WebServerResources/... curl -k -I https://127.0.0.1/SOGo.woa/WebServerResources/brow... curl -k -I https://127.0.0.1/SOGo/WebServerResources/browser_... (-I makes a HEAD request, so you should just see the http response headers.) > Before login there is GET /SOGoSOGo > After login there is POST /SOGoSOGoSOGo/ It looks like some part of the system is breaking this. I can't tell whether it is sogo itself, or nginx in front of it. > > The SOGo installation guide mentions an apache config file, and says > > "The default configuration will use mod_proxy and mod_headers to relay > > requests to the sogod parent process. This is suitable for small to > > medium deployments.". > > > Make me puzzle ... For instance , templates will not be loaded without this > : > location /SOGo.woa/WebServerResources/ { > alias /usr/lib/GNUstep/SOGo/WebServerResources/; > } That means that these requests are served by nginx from your filesystem. Are templates involved in the login problem, or the /SOGoSOGo problem you report? > I 'm going to get a look at internet for getting a sogo configuration file > for nginx. > Yet my configuration come from internet and as it didn't work I tried this > and that and this and passed too much time working on this issue. If I > managed to get it work I'll come back here for sharing. If you want to keep trying, I would suggest keeping your configuration as simple as possible, and only trying one thing at a time. Find out what exact requests must be made of the sogo server directly, and then configure nginx to produce them. I suspect that you will want something like location ^~ /SOGo/ { proxy_pass http://127.0.0.1:20000; } If you have just that, and you do curl -i -k https://127.0.0.1/SOGo/ do you get a useful response, and does it refer to /SOGoSOGo ? Based on that response, you can build the rest of the config. > Thank you indeed Francis for your time and the quality of yours answers. You're welcome. Good luck with it, f -- Francis Daly francis@daoine.org
on 2012-11-03 11:37
On Sat, Nov 03, 2012 at 10:21:55AM +0000, Francis Daly wrote: Small correction here: > > <link rel="shortcut icon" type="image/x-icon" > > href="https://sogo.mydomain/SOGo/WebServerResources/favi... /> > > So: sogo has been configured with its name, and doesn't just use the Host: > header it receives. Actually, that is almost certainly due to the proxy_set_header x-webobjects-server-url $scheme://$host; directive, so it isn't a specific configuration within sogo. Which suggests that you'll want this, plus some of the other "proxy_set_header x-webobjects-*" directives... > location ^~ /SOGo/ { > proxy_pass http://127.0.0.1:20000; > } ...in there too. f -- Francis Daly francis@daoine.org
Please log in before posting. Registration is free and takes only a minute.
Existing account
(Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
Log in with Google account | Log in with Yahoo account
No account? Register here.