Forum: NGINX Site URL not completed. Bad redirection ?

2974d09ac2541e892966b762aad84943?d=identicon&s=25 gerard breiner (Guest)
on 2012-10-29 14:58
(Received via mailing list)
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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-10-29 21:58
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 gerard breiner (Guest)
on 2012-10-30 16:11
(Received via mailing list)
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
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2012-10-30 18:16
(Received via mailing list)
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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-10-30 20:38
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 gerard breiner (Guest)
on 2012-10-31 12:03
(Received via mailing list)
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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-11-01 00:49
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 gerard breiner (Guest)
on 2012-11-02 22:50
(Received via mailing list)
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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-11-03 11:22
(Received via mailing list)
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
36a8284995fa0fb82e6aa2bede32adac?d=identicon&s=25 Francis Daly (Guest)
on 2012-11-03 11:37
(Received via mailing list)
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

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.