Re: tcpdump tls
я, кажется, вот на эту статью ориентировался: https://www.joji.me/en-us/blog/walkthrough-decrypt-ssl-tls-traffic-https-and-http2-in-wireshark/ On Mon, 27 Jul 2020 at 13:00, Slawa Olhovchenkov wrote: > > On Mon, Jul 27, 2020 at 02:44:37PM +0500, Илья Шипицин wrote: > > > у chrome есть net-internals > > > > https://support.google.com/chrome/a/answer/6271171?hl=en > > интересная штука, но похоже SSL там в нерасшифрованном виде и вопрос > ключей остается. > > > пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov : > > > > > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote: > > > > > > > 27.07.2020 0:47, Slawa Olhovchenkov пишет: > > > > > > > > > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > > > > > > > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет, > > > > > типа > > > > > > > > > > > > > > > Server's response > > > > > > > > > > Full response: > > > > > 0 Missing status code HTTP/1.1 > > > > > = > > > > > > > > > > > > > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что > > > > > именно пришло. > > > > > > > > В случае сеансовых ключей RSA можно попробовать в Wireshark: > > > > меню Редактирование/Параметры (Edit/Preference), > > > > дальше Protocols/TLS и там есть место вставить серверный ключ. > > > > > > И брать его из браузера? Как? > > > > > > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры > > > > дампить сессионные ключи, чтобы потом можно было их использовать в > > > Wireshark, > > > > в (Pre)-Master-Secret log filename. > > > > > > Отлично, меня это устроит, какие ключевые слова гуглить? > > > ___ > > > nginx-ru mailing list > > > nginx-ru@nginx.org > > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Возможно ли остановить выполнение правил внутри location/выйти из location
Максим, спасибо огромное! В итоге это именно то, что я и хотел получить.
>
>
> -- Forwarded message --
> From: Maksim Kulik
> To: nginx-ru@nginx.org
> Cc:
> Bcc:
> Date: Mon, 27 Jul 2020 09:54:02 +0300
> Subject: Re: Возможно ли остановить выполнение правил внутри
> location/выйти из location
> Можно после if делать внутренний редирект на другой локейшен (если,
> конечно, в вашем случае нет какой-то сложной дальнейшей обработки и вас
> интересует только то, что записано в location / ) при помощи error_page. То
> есть:
>
> error_page 420 = @special_location;
>
> location /test/lfs_lock_test.git/info/lfs/locks{
> if ( $args ~ "lockservice=true" ) {
> return 420;
> }
> rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
> proxy_pass https://localhost:5002;
> access_log /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
> error_log /var/log/gitlab/nginx/lfs_lock_error.log debug;
> }
>
> location @special_location {
> proxy_cache off;
> proxy_pass http://gitlab-workhorse;
> }
>
> пн, 27 июл. 2020 г. в 09:16, Роман Буренков :
>
>>
>> А какая была бы более правильная логика? Я изначально хотел сделать 2
>> правила с (?)(?!) но почему в таком regex`е у меня всё равно не тот url,
>> что я хотел просачивался в location ( location ~
>> (?^/.*.git/info/lfs/locks$)(?!^.*=true$))
>>
>>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
On Mon, Jul 27, 2020 at 02:44:37PM +0500, Илья Шипицин wrote: > у chrome есть net-internals > > https://support.google.com/chrome/a/answer/6271171?hl=en интересная штука, но похоже SSL там в нерасшифрованном виде и вопрос ключей остается. > пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov : > > > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote: > > > > > 27.07.2020 0:47, Slawa Olhovchenkov пишет: > > > > > > > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > > > > > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет, > > > > типа > > > > > > > > > > > > Server's response > > > > > > > > Full response: > > > > 0 Missing status code HTTP/1.1 > > > > = > > > > > > > > > > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что > > > > именно пришло. > > > > > > В случае сеансовых ключей RSA можно попробовать в Wireshark: > > > меню Редактирование/Параметры (Edit/Preference), > > > дальше Protocols/TLS и там есть место вставить серверный ключ. > > > > И брать его из браузера? Как? > > > > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры > > > дампить сессионные ключи, чтобы потом можно было их использовать в > > Wireshark, > > > в (Pre)-Master-Secret log filename. > > > > Отлично, меня это устроит, какие ключевые слова гуглить? > > ___ > > nginx-ru mailing list > > nginx-ru@nginx.org > > http://mailman.nginx.org/mailman/listinfo/nginx-ru > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
On Mon, Jul 27, 2020 at 04:32:20PM +0700, Eugene Grosbein wrote: > 27.07.2020 16:15, Slawa Olhovchenkov пишет: > > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote: > > >> В случае сеансовых ключей RSA можно попробовать в Wireshark: > >> меню Редактирование/Параметры (Edit/Preference), > >> дальше Protocols/TLS и там есть место вставить серверный ключ. > > > > И брать его из браузера? Как? > > Тут имелся в виду фиксированный серверный приватный ключ. > > >> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры > >> дампить сессионные ключи, чтобы потом можно было их использовать в > >> Wireshark, > >> в (Pre)-Master-Secret log filename. > > > > Отлично, меня это устроит, какие ключевые слова гуглить? > > Я гуглил так: wireshark decode https > Второй ссылкой было https://support.citrix.com/article/CTX116557 > How to Decrypt SSL and TLS Traffic Using Wireshark > > Четвертой https://wiki.wireshark.org/TLS#TLS_Decryption Key logging is enabled by setting the environment variable SSLKEYLOGFILE to point to a file. Note: starting with NSS 3.24 (used by Firefox 48 and 49 only), the SSLKEYLOGFILE approach is disabled by default for optimized builds using the Makefile (those using gyp via build.sh are not affected). Distributors can re-enable it at compile time though (using the NSS_ALLOW_SSLKEYLOGFILE=1 make variable) which is done for the official Firefox binaries. (See bug 1188657.) Notably, Debian does not have this option enabled, see Debian bug 842292. и народ на SO жалуется что хромы не пишут. даже с --ssl-key-log-file. The SSLKEYLOGFILE was originally disabled when the Mozilla team were debugging an NSS issue in Firefox 65. I had reported the bug here originally. It was subsequently reenabled in Firefox 66. However, once again for Firefox 67 it had accidentally been disabled in release builds again. I once again reopened that original bugzilla ticket to report it. And they then opened up a new bugzilla task that you linked in your post. A recent commit has removed the conditional that should now prevent that bug from reoccurring in future releases. My guess, the SSLKEYLOGFILE env. variable will work again when Firefox 68 releases, and on some Nightly version very shortly. ну ок, я понял как это врубить по крайне мере у себя. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
у chrome есть net-internals https://support.google.com/chrome/a/answer/6271171?hl=en пн, 27 июл. 2020 г. в 14:15, Slawa Olhovchenkov : > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote: > > > 27.07.2020 0:47, Slawa Olhovchenkov пишет: > > > > > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > > > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет, > > > типа > > > > > > > > > Server's response > > > > > > Full response: > > > 0 Missing status code HTTP/1.1 > > > = > > > > > > > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что > > > именно пришло. > > > > В случае сеансовых ключей RSA можно попробовать в Wireshark: > > меню Редактирование/Параметры (Edit/Preference), > > дальше Protocols/TLS и там есть место вставить серверный ключ. > > И брать его из браузера? Как? > > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры > > дампить сессионные ключи, чтобы потом можно было их использовать в > Wireshark, > > в (Pre)-Master-Secret log filename. > > Отлично, меня это устроит, какие ключевые слова гуглить? > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
27.07.2020 16:15, Slawa Olhovchenkov пишет: > On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote: >> В случае сеансовых ключей RSA можно попробовать в Wireshark: >> меню Редактирование/Параметры (Edit/Preference), >> дальше Protocols/TLS и там есть место вставить серверный ключ. > > И брать его из браузера? Как? Тут имелся в виду фиксированный серверный приватный ключ. >> Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры >> дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark, >> в (Pre)-Master-Secret log filename. > > Отлично, меня это устроит, какие ключевые слова гуглить? Я гуглил так: wireshark decode https Второй ссылкой было https://support.citrix.com/article/CTX116557 How to Decrypt SSL and TLS Traffic Using Wireshark Четвертой https://wiki.wireshark.org/TLS#TLS_Decryption ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
On Mon, Jul 27, 2020 at 02:43:44PM +0700, Eugene Grosbein wrote: > 27.07.2020 0:47, Slawa Olhovchenkov пишет: > > > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет, > > типа > > > > > > Server's response > > > > Full response: > > 0 Missing status code HTTP/1.1 > > = > > > > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что > > именно пришло. > > В случае сеансовых ключей RSA можно попробовать в Wireshark: > меню Редактирование/Параметры (Edit/Preference), > дальше Protocols/TLS и там есть место вставить серверный ключ. И брать его из браузера? Как? > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры > дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark, > в (Pre)-Master-Secret log filename. Отлично, меня это устроит, какие ключевые слова гуглить? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
On Mon, Jul 27, 2020 at 09:56:16AM +0300, Evgeniy Berdnikov wrote: > On Sun, Jul 26, 2020 at 08:47:40PM +0300, Slawa Olhovchenkov wrote: > > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > Это 7 вёрст крюк, проще включить на сервере debug log... иногда и в сервере бывают баги и хочется понять какая черепашка врет. (бага может быть и в драйвере сетевухи) ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
пн, 27 июл. 2020 г. в 12:44, Eugene Grosbein : > 27.07.2020 0:47, Slawa Olhovchenkov пишет: > > > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет, > > типа > > > > > > Server's response > > > > Full response: > > 0 Missing status code HTTP/1.1 > > = > > > > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что > > именно пришло. > > В случае сеансовых ключей RSA можно попробовать в Wireshark: > меню Редактирование/Параметры (Edit/Preference), > дальше Protocols/TLS и там есть место вставить серверный ключ. > тут, вероятно, стоит сделать оговорку про FPS (forward perfect secrecy). давным-давно, когда зрители фильмов про чебурашку еще были детьми, шифры были такие, что имея закрытый ключ сервера можно было декодировать SSL сессию. потом пришли безопасники, сказали "непорядок" и ввели FPS шифры (сейчас почти все такие, если вы специально не ограничите, и то, не факт, что современный браузер будет с таким работать). поэтому нужны сессионные ключи. которые можно стырить из браузера или из nginx (через специальную библиотеку) > > Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры > дампить сессионные ключи, чтобы потом можно было их использовать в > Wireshark, > в (Pre)-Master-Secret log filename. > > > > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
27.07.2020 0:47, Slawa Olhovchenkov пишет: > А что-как можно сделать что бы расшифровать https сессию в .pcap? > > Нет, не сорм. Просто клиентский браузер какую-то фигню странную пишет, > типа > > > Server's response > > Full response: > 0 Missing status code HTTP/1.1 > = > > > и я хочу своими глазами увидеть что конкретно ему отправилось и что > именно пришло. В случае сеансовых ключей RSA можно попробовать в Wireshark: меню Редактирование/Параметры (Edit/Preference), дальше Protocols/TLS и там есть место вставить серверный ключ. Для DHE/ECDHE сложнее, но вроде бы можно настроить популярные браузеры дампить сессионные ключи, чтобы потом можно было их использовать в Wireshark, в (Pre)-Master-Secret log filename. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: tcpdump tls
On Sun, Jul 26, 2020 at 08:47:40PM +0300, Slawa Olhovchenkov wrote: > А что-как можно сделать что бы расшифровать https сессию в .pcap? Это 7 вёрст крюк, проще включить на сервере debug log... > и я хочу своими глазами увидеть что конкретно ему отправилось и что > именно пришло. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Возможно ли остановить выполнение правил внутри location/выйти из location
Можно после if делать внутренний редирект на другой локейшен (если,
конечно, в вашем случае нет какой-то сложной дальнейшей обработки и вас
интересует только то, что записано в location / ) при помощи error_page. То
есть:
error_page 420 = @special_location;
location /test/lfs_lock_test.git/info/lfs/locks{
if ( $args ~ "lockservice=true" ) {
return 420;
}
rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
proxy_pass https://localhost:5002;
access_log /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
error_log /var/log/gitlab/nginx/lfs_lock_error.log debug;
}
location @special_location {
proxy_cache off;
proxy_pass http://gitlab-workhorse;
}
пн, 27 июл. 2020 г. в 09:16, Роман Буренков :
>
> А какая была бы более правильная логика? Я изначально хотел сделать 2
> правила с (?)(?!) но почему в таком regex`е у меня всё равно не тот url,
> что я хотел просачивался в location ( location ~
> (?^/.*.git/info/lfs/locks$)(?!^.*=true$))
>
> вс, 26 июл. 2020 г. в 15:00, :
>
>> Сообщения, предназначенные для списка
>> рассылки nginx-ru, отправляйте по адресу
>> nginx-ru@nginx.org
>>
>> Для изменения параметров подписки или
>> отписки используйте веб-страницу
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> или отправьте письмо, в теле или теме
>> которого будет слово 'help', по адресу
>> nginx-ru-requ...@nginx.org
>>
>> Адрес администратора этого списка
>> рассылки:
>> nginx-ru-ow...@nginx.org
>>
>> При ответе, пожалуйста, измените тему
>> письма на более содержательную чем "Re:
>> Содержание дайджеста списка рассылки
>> nginx-ru..."
>> В этом номере:
>>
>>1. Возможно ли остановить
>> выполнение правил внутри
>> location/выйти из location (Роман Буренков)
>>2. Re: Возможно ли остановить
>> выполнение правил внутри
>> location/выйти из location (Сергей Олегович)
>>
>>
>>
>> -- Forwarded message --
>> From: "Роман Буренков"
>> To: nginx-ru@nginx.org
>> Cc:
>> Bcc:
>> Date: Sun, 26 Jul 2020 12:11:20 +0300
>> Subject: Возможно ли остановить выполнение правил внутри location/выйти
>> из location
>> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
>> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>>
>> кусок моего location с правилами:
>>
>> location /test/lfs_lock_test.git/info/lfs/locks{
>> if ( $args ~ "lockservice=true" ) {
>> return 404;
>> }
>> rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>> proxy_pass https://localhost:5002;
>> access_log /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>> error_log /var/log/gitlab/nginx/lfs_lock_error.log debug;
>> }
>>
>> я хочу обрабатывать все запросы на ^.*.git/info/lfs/locks внутри location,
>> только если там не содержится lockservice=true в URI, в это случае,
>> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
>> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>>
>> location / {
>> proxy_cache off;
>> proxy_pass http://gitlab-workhorse;
>> }
>>
>> т.е. если есть lockservice=true в URI, то не делать proxy_pass и в принципе
>> не применять правила из моего location
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- Forwarded message --
>> From: "Сергей Олегович"
>> To:
>> Cc:
>> Bcc:
>> Date: Sun, 26 Jul 2020 12:28:43 +0300
>> Subject: Re: Возможно ли остановить выполнение правил внутри
>> location/выйти из location
>> Можно в if засунуть rewrite ... last; Тогда после выполнения условия
>> будет совершён выход из этого location и поиск нового в соответствии с
>> изменениями. Но мне сходу видятся проблемы, т.к. изначально логика
>> построена неверно.
>>
>> Роман Буренков 26 июля 2020 г. 12:11:41 написал:
>>
>>> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
>>> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>>>
>>> кусок моего location с правилами:
>>>
>>> location /test/lfs_lock_test.git/info/lfs/locks{
>>> if ( $args ~ "lockservice=true" ) {
>>> return 404;
>>> }
>>> rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>>> proxy_pass https://localhost:5002;
>>> access_log /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>>> error_log /var/log/gitlab/nginx/lfs_lock_error.log debug;
>>> }
>>>
>>> я хочу обрабатывать все запросы на ^.*.git/info/lfs/locks внутри location,
>>> только если там не содержится lockservice=true в URI, в это случае,
>>> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
>>> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>>>
>>> location / {
>>> proxy_cache off;
>>> proxy_pass http://gitlab-workhorse;
>>> }
>>>
>>> т.е. если есть lockservice=true в URI, то не делать proxy_pass и в
>>> принципе не применять правила из моего location
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> nginx-ru mailing list
>>> nginx-ru@nginx.org
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>
>>
Re: Возможно ли остановить выполнение правил внутри location/выйти из location
А какая была бы более правильная логика? Я изначально хотел сделать 2
правила с (?)(?!) но почему в таком regex`е у меня всё равно не тот url,
что я хотел просачивался в location ( location ~
(?^/.*.git/info/lfs/locks$)(?!^.*=true$))
вс, 26 июл. 2020 г. в 15:00, :
> Сообщения, предназначенные для списка
> рассылки nginx-ru, отправляйте по адресу
> nginx-ru@nginx.org
>
> Для изменения параметров подписки или
> отписки используйте веб-страницу
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> или отправьте письмо, в теле или теме
> которого будет слово 'help', по адресу
> nginx-ru-requ...@nginx.org
>
> Адрес администратора этого списка
> рассылки:
> nginx-ru-ow...@nginx.org
>
> При ответе, пожалуйста, измените тему
> письма на более содержательную чем "Re:
> Содержание дайджеста списка рассылки
> nginx-ru..."
> В этом номере:
>
>1. Возможно ли остановить
> выполнение правил внутри
> location/выйти из location (Роман Буренков)
>2. Re: Возможно ли остановить
> выполнение правил внутри
> location/выйти из location (Сергей Олегович)
>
>
>
> -- Forwarded message --
> From: "Роман Буренков"
> To: nginx-ru@nginx.org
> Cc:
> Bcc:
> Date: Sun, 26 Jul 2020 12:11:20 +0300
> Subject: Возможно ли остановить выполнение правил внутри location/выйти из
> location
> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>
> кусок моего location с правилами:
>
> location /test/lfs_lock_test.git/info/lfs/locks{
> if ( $args ~ "lockservice=true" ) {
> return 404;
> }
> rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
> proxy_pass https://localhost:5002;
> access_log /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
> error_log /var/log/gitlab/nginx/lfs_lock_error.log debug;
> }
>
> я хочу обрабатывать все запросы на ^.*.git/info/lfs/locks внутри location,
> только если там не содержится lockservice=true в URI, в это случае,
> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>
> location / {
> proxy_cache off;
> proxy_pass http://gitlab-workhorse;
> }
>
> т.е. если есть lockservice=true в URI, то не делать proxy_pass и в принципе
> не применять правила из моего location
>
>
>
>
>
>
>
>
>
> -- Forwarded message --
> From: "Сергей Олегович"
> To:
> Cc:
> Bcc:
> Date: Sun, 26 Jul 2020 12:28:43 +0300
> Subject: Re: Возможно ли остановить выполнение правил внутри
> location/выйти из location
> Можно в if засунуть rewrite ... last; Тогда после выполнения условия будет
> совершён выход из этого location и поиск нового в соответствии с
> изменениями. Но мне сходу видятся проблемы, т.к. изначально логика
> построена неверно.
>
> Роман Буренков 26 июля 2020 г. 12:11:41 написал:
>
>> Я использую gitlab 12 СE ( 12.9.2 (ac5568eb5d8) ) и nginx из поставки
>> gitlab (nginx 1.16.1 sha256:f11c2a6d )
>>
>> кусок моего location с правилами:
>>
>> location /test/lfs_lock_test.git/info/lfs/locks{
>> if ( $args ~ "lockservice=true" ) {
>> return 404;
>> }
>> rewrite ^/test/lfs_lock_test.git/(.*) /$1 break;
>> proxy_pass https://localhost:5002;
>> access_log /var/log/gitlab/nginx/lfs_lock_access.log gitlab_access;
>> error_log /var/log/gitlab/nginx/lfs_lock_error.log debug;
>> }
>>
>> я хочу обрабатывать все запросы на ^.*.git/info/lfs/locks внутри location,
>> только если там не содержится lockservice=true в URI, в это случае,
>> просто выйти из location ( без 404 ) ,т.к. в файле, который я правлю
>> ( /var/opt/gitlab/nginx/conf/gitlab-http.conf ) есть в т.ч. и такое:
>>
>> location / {
>> proxy_cache off;
>> proxy_pass http://gitlab-workhorse;
>> }
>>
>> т.е. если есть lockservice=true в URI, то не делать proxy_pass и в принципе
>> не применять правила из моего location
>>
>>
>>
>>
>>
>>
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
