>> Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А
>> на стороне сервера считаешь хэш от логина, пароля, подсети и salt и
>> смотришь, равен ли он тому, что пришёл в куках.
Суёшь в авторизационную куку логин пользователя, время жизни
авторизации, salt, и хэш от логина, п
Здравствуйте, All!
Как сделать Mutual authentication
между двумя сервисами с помощью nginx?
На двух разных серверах nginx слушает на порту 443
и проксирует клиентские запросы на порт 80 backend`а.
"На вход" проверка клиентского сертификата работает отлично.
А когда backend делает клиентский зап
On 21.01.2014 00:40, Михаил Монашёв wrote:
Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А
на стороне сервера считаешь хэш от логина, пароля, подсети и salt и
смотришь, равен ли он тому, что пришёл в куках.
Я не специалист по криптографии, но насколько понимаю просто
Здравствуйте, oklas.
Всё просто. Суёшь в авторизационную куку логин пользователя и хэш. А
на стороне сервера считаешь хэш от логина, пароля, подсети и salt и
смотришь, равен ли он тому, что пришёл в куках. Можно ещё юзерагента
добавить по желанию. Такая авторизация привязывает юзера
20.01.2014 20:28, Anton Kiryushkin пишет:
Да, это само собой. На 1-м у меня сейчас так:
proxy_set_header X-Real-IP $remote_addr;
Тогда на втором сервере должно быть
set_real_ip_from ;
real_ip_header X-Real-IP;
И смотрите что в логи пишется.
--
Best regards,
Andrey Kope
Всем Доброго дня!
Давно здесь видел тему не могу найти. Там обсуждались способы авторизации
пользователя, использование redis для привязки куки и пользователя и
прочее.
Был предложен метод при котором redis/memcached и т.п. не используются
а пользователь и пароль шифруются и засовываются в куки и
On 01/20/14 20:28, Anton Kiryushkin wrote:
Да, это само собой. На 1-м у меня сейчас так:
proxy_set_header X-Real-IP $remote_addr;
Ну тогда нужно смотреть debug log на 2-м nginx.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://m
Да, это само собой. На 1-м у меня сейчас так:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
20 января 2014 г., 20:10 пользователь Anton Yuzhaninov
написал:
> On
On 01/20/14 20:03, Anton Kiryushkin wrote:
Первичный вывод сделан на основе прописывания на втором nginx в конфиге хоста
опций:
set_real_ip_from
real_ip_header
Еще на 1-м nginx нужно
proxy_set_header $remote_addr;
___
nginx-ru mailing list
nginx
Всем доброго времени суток.
Скажите, пожалуйста, правда ли, что если использовать proxy_pass https://,
где этот самый proxy_pass слушает такой же nginx, то второму nginx никак не
получить client_ip ?
Первичный вывод сделан на основе прописывания на втором nginx в конфиге
хоста опций:
set_real_ip
On Jan 20, 2014, at 15:27 , Anatoly Mikhailov wrote:
>
> On 20 Jan 2014, at 11:02, Igor Sysoev wrote:
>
>> On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote:
>>
>>> в нашем случае - локально настроенная Jira с 10 пользователями,
>>> сомневаюсь, что приложение загнется при такой нагрузке.
>>>
On 20 Jan 2014, at 11:02, Igor Sysoev wrote:
> On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote:
>
>> в нашем случае - локально настроенная Jira с 10 пользователями,
>> сомневаюсь, что приложение загнется при такой нагрузке.
>>
>> и все же, кто как кэширует статику, сгенерированную налету?
On Jan 20, 2014, at 14:52 , Anatoly Mikhailov wrote:
> в нашем случае - локально настроенная Jira с 10 пользователями,
> сомневаюсь, что приложение загнется при такой нагрузке.
>
> и все же, кто как кэширует статику, сгенерированную налету?
http {
proxy_cache_path /path/to/cache keys_zone=
https://jira..ru/s/ru_RUsu9vq5-1988229788/6097/5/e1f48b4b2dac40253e06ee982f4b3682/_/download/contextbatch/css/atl.general,jira.global/batch.css
- прилетает с хедерами, позволяющими кеш
если вы включите обычный кеш на nginx - будет кешироваться если не
включите, будет кешить сам браузер, что при
в нашем случае - локально настроенная Jira с 10 пользователями,
сомневаюсь, что приложение загнется при такой нагрузке.
и все же, кто как кэширует статику, сгенерированную налету?
Анатолий
On 20 Jan 2014, at 10:35, Илья Шипицин wrote:
> у jira, teamcity узкое место - само приложение. оно начин
у jira, teamcity узкое место - само приложение. оно начинает
загибаться гораздо раньше, чем становятся заметны проблемы с отдачей
статики.
оптимизировать именно статику в данном случае - предпосылка непонятная
20 января 2014 г., 14:30 пользователь Anatoly Mikhaylov
написал:
> Вопрос не в количест
On 20 Jan 2014, at 09:04, S.A.N wrote:
Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не
>> препятствовало основному проксированию ответа
>
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache
гуглить умею, администрировать тоже, интересует кто и как реш
> >> Вопрос, как кэшировать ответы от бэкэнда (статику), чтобы это не
> препятствовало основному проксированию ответа
http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_cache
Posted at Nginx Forum:
http://forum.nginx.org/read.php?21,246604,246613#msg-246613
___
Вопрос не в количестве статики, а в том, что весьма неуклюже гонять http
запросы за ее получением через Catalina.
Http 1.1 с keep-alive, ConditionalGet для статики - это лишь попытка прикрыть
глупость организации отдачи контента, который, во многих случаях, не меняется
никогда. Одно дело - все
19 matches
Mail list logo
