Site URL not completed. Bad redirection?

Server NGINX
1

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:

2

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 Module ngx_http_core_module

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 D. [email protected]

3

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:

4

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 D. [email protected]

5

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:

6

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 D. [email protected]

7

On 30 October 2012 15:11, gerard breiner [email protected] 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 M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

8

Hello Francis,

Francis D. 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"?> WEBMAIL I.A.S. 
  </head>

  <body class="popup">
*

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.

Download Firefox *

Alternatively, you can also use the following compatible browsers

Download Chrome *

Download Safari *
SOGo requires Javascript to run. Please make sure this option is available and activated within your browser preferences.

Retry
--------------------------------------------------------------------------------------

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 D. [email protected]

nginx mailing list
[email protected]
nginx Info Page

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:

9

On Fri, Nov 02, 2012 at 05:50:08PM -0400, gerard breiner wrote:

Francis D. 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

So: sogo has been configured with its name, and doesn’t just use the
Host:
header it receives.

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.

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 *

/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/browser_firefox.gif?lm=1351283693
curl -k -I
https://127.0.0.1/SOGo.woa/WebServerResources/browser_firefox.gif?lm=1351283693
curl -k -I
https://127.0.0.1/SOGo/WebServerResources/browser_firefox.gif?lm=1351283693

(-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 D. [email protected]

10

On Sat, Nov 03, 2012 at 10:21:55AM +0000, Francis D. wrote:

Small correction here:

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 D. [email protected]