auth_request off; ignored when combined with auth_basic;

[Stian Øvrevåge]

Hi list,

I have a server {} block that is protected with auth_request; on the top level.

auth_request is used for a interactive login process.

I have some endpoints that will receive data from other software, and
must instead be protected by auth_basic. However, "auth_request off;"
is ignored in these location{} blocks IF there is also a auth_basic
statement in the block.

This works without logging in:
   location /test/ {
  auth_request off;
  proxy_pass http://localhost:88/;
   }

This is automatically redirected back to /security/ for login (as
defined by auth_request in server{} block.
   location /api/ {
  auth_request "off";
  auth_basic "Restricted access";
  auth_basic_user_file /etc/htpasswd;
  proxy_pass http://localhost:88/;
   }

I see online references to a "satisfy any" directive that apparently
worked a few years ago, but it does not anymore, and others are
reporting similar problems:
https://stackoverflow.com/questions/42301559/nginx-with-auth-request-and-auth-basic

Brgds,
Stian Øvrevåge
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

[nginx] Fixed type of ngx_conf_t.handler_conf.

[Ruslan Ermilov]

details:   http://hg.nginx.org/nginx/rev/dc3b3cfd5d23
branches:  
changeset: 7133:dc3b3cfd5d23
user:  Ruslan Ermilov 
date:  Fri Oct 13 00:32:26 2017 +0300
description:
Fixed type of ngx_conf_t.handler_conf.

The type should have been changed in c9b243802a17 along with
changing ngx_conf_handler_pt.

diffstat:

 src/core/ngx_conf_file.h |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff -r 8076ba459f05 -r dc3b3cfd5d23 src/core/ngx_conf_file.h
--- a/src/core/ngx_conf_file.h  Wed Oct 11 15:43:50 2017 -0700
+++ b/src/core/ngx_conf_file.h  Fri Oct 13 00:32:26 2017 +0300
@@ -128,7 +128,7 @@ struct ngx_conf_s {
 ngx_uint_tcmd_type;
 
 ngx_conf_handler_pt   handler;
-char *handler_conf;
+void *handler_conf;
 };
 
 
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: WebDAV behind a nginx reverse proxy

[Reinis Rozitis]

This is my current vhost for the webdav access on the nginx rev. proxy:

[..]
 If I switch the vhost to listen on port 80 without ssl, everything is 
fine and files can be renamed or moved via webdav.


If it works on http but not with ssl it might indicate that either this 
configuration part doesn't work as expected:


set $dest $http_destination;

if ($http_destination ~ "^https://(.+)") {
   set $dest http://$1;
}
proxy_set_header Destination $dest;


or depending on the backend application maybe statically setting 
proxy_set_header X-Forwarded-Proto http; is wrong as usually you need to 
pass the actual protocol used for the application to respond correctly and 
construct the URLs using the right schema.


I would try changing it to:

proxy_set_header X-Forwarded-Proto $scheme;




Also every hint how to debug such kind of problems are highly wellcome


One way to debug would be using something like tcpdump either on the nginx 
or apache host to inspect the http headers passed and/or adding them to 
access logs to see what goes wrong. But some parts you can check also on 
frontend with browser - for example the Destination header by adding it to 
nginx configuration:


add_header Destination $dest;



As far as I understand you are using nginx as an SSL offloader?
Is there anything else you do on the proxy?

If not maybe it's more easy to use the stream module ( 
http://nginx.org/en/docs/stream/ngx_stream_core_module.html ) and ssl 
offload on tcp level rather than deal with the http/headers between (though 
there is a drawback of not getting the real client ip (in a http header) on 
the backend server / hope for PROXY protocol support for backends one day).


In short something like:

stream {
   upstream stream_backend {
   server your.apache.backend:80;
   }
   server {
   listen 443 ssl;
   proxy_pass stream_backend;
   proxy_ssl_certificate  cert.crt;
   proxy_ssl_certificate_key cert.key;
   }
}


Also  https://www.nginx.com/resources/admin-guide/nginx-tcp-ssl-termination/

rr 


___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Правильно отдать статику

[abramov90]

Base  не подходит, потому что у меня на сервере алиас еще один хост и это
две разные аппликации 

Один хост domain.io
Второй хост my.domain.io

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,276842,276844#msg-276844

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Правильно отдать статику

[Aleksandr Sytar]

12 октября 2017 г., 18:24 пользователь abramov90 <
nginx-fo...@forum.nginx.org> написал:

> Всем доброго времени суток, я фронт енд разработчик, потому сильно не
> ругайте, думаю, вопрос относительно банальный, у меня SPA, но когда я
> перехожу на урлу типа
>
> hostname/page/subpage сервер (при этом, пути на статику у меня
> относительные, в силу особенность аппликации не могу установить абсолютные)
>
> то браузер соответственно ищет статику по адресу hostname/page/js
>
...

>
> как сделать правильно?
>

Задать тег base, чтобы относительные URL считались от него, а не от текущей
страницы.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: [PATCH] SSL: include

[Maxim Dounin]

Hello!

On Wed, Oct 11, 2017 at 03:58:37PM -0700, Alessandro Ghedini wrote:

> # HG changeset patch
> # User Alessandro Ghedini 
> # Date 1507761830 25200
> #  Wed Oct 11 15:43:50 2017 -0700
> # Node ID fe296bd63e074759392076a2bb6b36f77301227d
> # Parent  fe7d9e3987d40f16d86fd01d94ad16ff58467af2
> SSL: include 
> 
> This header carries the definition of HMAC_Init_ex(). In OpenSSL this
> header is included by , but it's not so in BoringSSL.
> 
> It's probably a good idea to explicitly include this header anyway,
> regardless of whether it's included by other headers or not.
> 
> diff -r fe7d9e3987d4 -r fe296bd63e07 src/event/ngx_event_openssl.h
> --- a/src/event/ngx_event_openssl.h   Wed Sep 28 14:54:44 2016 +0100
> +++ b/src/event/ngx_event_openssl.h   Wed Oct 11 15:43:50 2017 -0700
> @@ -22,6 +22,7 @@
>  #include 
>  #endif
>  #include 
> +#include 
>  #ifndef OPENSSL_NO_OCSP
>  #include 
>  #endif

Committed (with a dot added to the summary line), thanks.
http://hg.nginx.org/nginx/rev/8076ba459f05

-- 
Maxim Dounin
http://nginx.org/
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

[nginx] SSL: include .

[Maxim Dounin]

details:   http://hg.nginx.org/nginx/rev/8076ba459f05
branches:  
changeset: 7132:8076ba459f05
user:  Alessandro Ghedini 
date:  Wed Oct 11 15:43:50 2017 -0700
description:
SSL: include .

This header carries the definition of HMAC_Init_ex(). In OpenSSL this
header is included by , but it's not so in BoringSSL.

It's probably a good idea to explicitly include this header anyway,
regardless of whether it's included by other headers or not.

diffstat:

 src/event/ngx_event_openssl.h |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diffs (11 lines):

diff --git a/src/event/ngx_event_openssl.h b/src/event/ngx_event_openssl.h
--- a/src/event/ngx_event_openssl.h
+++ b/src/event/ngx_event_openssl.h
@@ -22,6 +22,7 @@
 #include 
 #endif
 #include 
+#include 
 #ifndef OPENSSL_NO_OCSP
 #include 
 #endif
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Ошибка при использовании Reverse proxy и ssl

[Maxim Dounin]

Hello!

On Thu, Oct 12, 2017 at 12:32:53AM -0400, emejibka wrote:

> Здравствуйте.
> Неожиданно один из сайтов перестал работать извне. В логах появились ошибки
> 2017/10/12 09:22:19 [error] 10729#0: *580 peer closed connection in SSL
> handshake (54: Connection reset by peer) while SSL handshaking to upstream,
> client: 83.169.216.72, server: mydomain.ru, request: "GET /favicon.ico
> HTTP/1.1", upstream: "https://192.168.255.4:443/favicon.ico;, host:
> "mydomain.ru", referrer: "https://mydomain.ru/;
> 
> Nginx настроен следующим образом
> server {
> listen   443 ssl;
> server_name  mydomain.ru;
> 
> ssl_certificate  /usr/local/etc/nginx/ssl/certificate.crt;
> ssl_certificate_key  /usr/local/etc/nginx/ssl/private.key;
> 
> location / {
> proxy_pass https://mydomain.ru;
> }
> }
> 
> Сертификаты на серверах одинаковые, mydomain.ru разрешается в разные адреса
> в зависимости от адреса клиента, т.е. клиенты извне присылают запросы на
> nginx, тот пересылает запросы на сервер внутри сети, клиенты в локальной
> сети отправляют запросы на сервер, минуя nginx.
> 
> Я не могу никак понять почему nginx сам разрешает имя mydomain.ru в
> локальный ip адрес и посылает запрос используя ip адрес, а не доменное имя.

А что вы понимаете под словами "посылает запрос используя ip 
адрес, а не доменное имя"?  Послать HTTP-запрос, используя 
доменное имя, невозможно.  Нужно превратить имя в IP-адрес, 
установить с ним соединение, и после этого посылать запрос.

В сообщении об ошибке явно указано, с каким адресом nginx пытался 
общаться, когда произошла ошибка - 192.168.255.4.  Если это 
правильный адрес - то дальше надо разбираться, почему 
соответствующий бекенд закрыл соединение.  Если неправильный - 
надо разбираться, почему он неправильный.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

WebDAV behind a nginx reverse proxy

[Christian Schoepplein]

Hi,

I've installed nginx as a reverse proxy in front of an apache webdav 
server. Everything seems to be OK so far, but renaming or moving files 
failes.

This is my current vhost for the webdav access on the nginx rev. proxy:

server {
  listen 443 ssl;
  server_name 
"~^(?(webdav|schulweb))\-ca(?\d{4})\-(?(muenchen|augsburg))\.musin\.de$";

  dav_methods PUT DELETE MKCOL COPY MOVE;
  dav_ext_methods PROPFIND OPTIONS;

  location / {
resolver ns.musin.de;
set $target $part1.ca$part2.$part3.musin.de;
proxy_pass http://$target:80;

client_max_body_size 0;

set $dest $http_destination;

if ($http_destination ~ "^https://(.+)") {
  set $dest http://$1;
}

proxy_set_header Destination $dest;
proxy_http_version 1.1;
proxy_buffering off;
proxy_read_timeout 300;
proxy_send_timeout 300;
proxy_pass_request_headers on;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto http;
proxy_set_header X-Forwarded-User $http_authorization;
proxy_set_header Host $target;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Accept-Encoding "";
proxy_pass_header Date;
proxy_pass_header Server;
proxy_pass_header Authorization;
more_set_input_headers 'Authorization: $http_authorization';
more_set_headers -s 401 'WWW-Authenticate: Basic realm="$target"';
  }

  access_log  /var/log/nginx/webdav-access.log upstreamlog;
  error_log /var/log/nginx/webdav-error.log warn;
}

If I switch the vhost to listen on port 80 without ssl, everything is 
fine and files can be renamed or moved via webdav.

I think the problem is related to this thread, but however, the solution 
described there does unfortunatly not help:

http://mailman.nginx.org/pipermail/nginx/2007-January/000504.html

I am absolutely no nginx, proxy or http  expert, so maybe some settings 
in the config above are wrong. If you see anything that is strange or 
can be removed or should be changed, please let me know. Also every idea 
how to solve my problem would be great. Also every hint how to debug 
such kind of problems are highly wellcome :-).

Cheers and thanks,

  Schoepp

-- 
Christian Schoepplein

Landeshauptstadt Muenchen
Referat fuer Bildung und Sport
Zentrum fuer Informationstechnologie im Bildungsbereich (ZIB)
- Netze und Servermanagement

Postanschrift:  Bueroanschrift:

Landeshauptstadt Muenchen   Landeshauptstadt Muenchen
Referat fuer Bildung und Sport  Referat fuer Bildung und Sport
PostfachBayerstr. 28 (Raum 5.326)

80313 Muenchen  80335 Muenchen

T: +49 (0)89 233-85906
E: c.schoepplein (at) musin.de
I: http://www.zib.musin.de

Elektronische Kommunikation mit der Landeshauptstadt Muenchen, siehe: 
http://www.muenchen.de/ekomm

Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. Pro 
Blatt sparen Sie durchschnittlich 15g Holz, 260ml Wasser, 0,05kWh Strom 
und 5g CO2.

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Reverse cache not working on start pages (solution founD)

[Lucas Rolff]

If your server gets hacked due to a single website, you have bigger problems, 
and mod_security won’t fix the issue.
Consult with security professionals or give the task of managing your 
infrastructure to someone that can properly secure the environment.

On 12/10/2017, 13.26, "nginx on behalf of Dingo"  wrote:

You are right. I didn't know what canonical url:s where, but now I know. Yes
there is in fact two servers. One server is running Apache with a website
that has maybe 10 different DNS-domains pointing to it and then there is
another server running IIS with lots of websites but usually only one
DNS-domain pointing to each of them. The IIS server has a control panel
software that enables customers to add both websites and DNS-records, so I
don't want to change the configuration in my nginx proxy every time someone
adds or changes something on that server, so there needs to be a bit of
compromising.

I have very limited knowledge about how to configure and protect webservers
and the reason all this is happening now, is that the IIS server has been
hacked due to an old wordpress vulnerability in a plugin called revslider,
so I have had to do things in a bit of a hurry. When I installed nginx i
didn't know that it was revslider, so nginx didn't fix the problem, so the
server got hacked once again. I have now installed modsecurity, which seems
to have stopped the problem.

I am seriously considering using nginx plus, but it's not entirely my
decision and my colleagues are already upset over all cost surrounding the
web-servers at the moment.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,276670,276836#msg-276836

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx


___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Reverse cache not working on start pages (solution founD)

[Dingo]

You are right. I didn't know what canonical url:s where, but now I know. Yes
there is in fact two servers. One server is running Apache with a website
that has maybe 10 different DNS-domains pointing to it and then there is
another server running IIS with lots of websites but usually only one
DNS-domain pointing to each of them. The IIS server has a control panel
software that enables customers to add both websites and DNS-records, so I
don't want to change the configuration in my nginx proxy every time someone
adds or changes something on that server, so there needs to be a bit of
compromising.

I have very limited knowledge about how to configure and protect webservers
and the reason all this is happening now, is that the IIS server has been
hacked due to an old wordpress vulnerability in a plugin called revslider,
so I have had to do things in a bit of a hurry. When I installed nginx i
didn't know that it was revslider, so nginx didn't fix the problem, so the
server got hacked once again. I have now installed modsecurity, which seems
to have stopped the problem.

I am seriously considering using nginx plus, but it's not entirely my
decision and my colleagues are already upset over all cost surrounding the
web-servers at the moment.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,276670,276836#msg-276836

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Reverse cache not working on start pages (solution founD)

[Peter Booth]

Sounds like the problem is that you don’t have nginx configured to enforce 
canonical urls. 
What do I mean by this?

Imagine that every page on the site has one and only one “correct URL”

So someone might type 

http://www.mydomain.com
http://mydomain.com
http://www.mydomain.com/index.html

and expect to see the same page. A site that enforces canonical URLs would do a 
redirect 
from the non-canonical URL so the web server end up being queried of the 
canonical URL, 
which would be cached correctly.

There is one good and one blah reason to do this. The first (good) reason is 
about predictability,
 and making easy to solve problems. The second reason is for better SEO, though 
there are 
other techniques to solve it. 

There are so many things that can go wrong or trip us up on websites which is 
why ensuring
 predictability whenever possible reduces the population of potential error 
causes.

Peter


> On Oct 12, 2017, at 4:52 AM, Dingo  wrote:
> 
> I found the solution, but I don't understand what it does. When I add:
> 
> proxy_cache_key "$host$uri$is_args$args";
> 
> To a location block it magically works. I have no clue what happens, it was
> just a snippet I found on the Internet used by some other guy setting up a
> reverse proxy with cache.
> 
> And thanks to Maxim and pbooth for trying to help me.
> 
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?2,276670,276833#msg-276833
> 
> ___
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

[nginx] Upstream: disabled upgrading in subrequests.

[Roman Arutyunyan]

details:   http://hg.nginx.org/nginx/rev/6a5a91de5b74
branches:  
changeset: 7131:6a5a91de5b74
user:  Roman Arutyunyan 
date:  Wed Oct 11 17:38:21 2017 +0300
description:
Upstream: disabled upgrading in subrequests.

Upgrading an upstream connection is usually followed by reading from the client
which a subrequest is not allowed to do.  Moreover, accessing the header_in
request field while processing upgraded connection ends up with a null pointer
dereference since the header_in buffer is only created for the the main request.

diffstat:

 src/http/ngx_http_upstream.c |  7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diffs (17 lines):

diff -r 882ad033d43c -r 6a5a91de5b74 src/http/ngx_http_upstream.c
--- a/src/http/ngx_http_upstream.c  Wed Oct 11 22:04:28 2017 +0300
+++ b/src/http/ngx_http_upstream.c  Wed Oct 11 17:38:21 2017 +0300
@@ -3206,6 +3206,13 @@ ngx_http_upstream_upgrade(ngx_http_reque
 
 /* TODO: prevent upgrade if not requested or not possible */
 
+if (r != r->main) {
+ngx_log_error(NGX_LOG_ERR, c->log, 0,
+  "connection upgrade in subrequest");
+ngx_http_upstream_finalize_request(r, u, NGX_ERROR);
+return;
+}
+
 r->keepalive = 0;
 c->log->action = "proxying upgraded connection";
 
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: Reverse cache not working on start pages (solution founD)

[Dingo]

I found the solution, but I don't understand what it does. When I add:

proxy_cache_key "$host$uri$is_args$args";

To a location block it magically works. I have no clue what happens, it was
just a snippet I found on the Internet used by some other guy setting up a
reverse proxy with cache.

And thanks to Maxim and pbooth for trying to help me.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,276670,276833#msg-276833

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Reverse cache not working on start pages

[Dingo]

Thanks for the help, and I have found the solution now, so I will post it in
this thread.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,276670,276832#msg-276832

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Reverse cache not working on start pages

[Dingo]

I believe that there is sometimes a problem with the cache when i connect
through a private IP-address instead of always using the public address.
Since I started to always use the public address and a hairpin-nat, it
always works. Maybe the cache has a problem when seeing me coming from
different IP addresses. This didn't however help me with my start page
problem, but I have found the solution now. I will write a new post in this
thread about that. Thanks for the help.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?2,276670,276831#msg-276831

___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx

Re: Proxy_cache

[Dmitriy Lyalyuev]

Боюсь, что эти вопросы не относятся к теме рассылки.
Вам стоит сходить куда-то на StackOverflow или Toster. Обычно подобные
вопросы задают там.

Тут обсуждают Nginx и его модули/конфигурации.

2017-10-12 6:19 GMT+03:00 demolitionman :

> Чуть не забыл pgsql между собой тоже синхронизируются, какой софт
> посоветуете для этого?
>
> Posted at Nginx Forum: https://forum.nginx.org/read.
> php?21,122768,276827#msg-276827
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
With best regards,
Dmitriy Lyalyuev
https://lyalyuev.info
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru