Re: nginx и проксирование
06.10.2018 13:46, Victor Wagner пишет:
> On Sat, 6 Oct 2018 12:56:42 +0300
> artiom <artiom14@yandex.ru> wrote:
>
>> 05.10.2018 22:54, Victor Wagner пишет:
>>> В Fri, 5 Oct 2018 22:32:47 +0300
>>> artiom <artiom14@yandex.ru> пишет:
>>>
>>>> Да, nginx ни в чём, ни в чём не виноват.
>>>> Это на странице прописано включение css от корня и браузер,
>>>> соответственно, делает GET запрос.
>>>> Вопрос, как сделать, не заводя корень, и возможно ли это?
>>>
>>> А подумать? Вот у нас есть поток данных, идущих от сервера к
>>> браузеру через proxy.
>>>
>> Вот через подумать и выходит, что технически это возможно.
>>
>>> Вот где-то внутри этого потока данных js-код, формирующий URL
>>> запроса. По-моему, очевидно, что прошерстить весь этот код и
>>> выловить URL, чтобы их переписать - задача в общем виде не
>>> разрешимая.
>>> Так и не требуется. Достаточно подменить PUT/POST/GET/etc.,
>>> обращающиеся
>
> Где подменить? На клиенте? На proxy-то не получится.
>
Вот именно тут и есть проблема. На прокси получится. Только для этого
ему нужно понимать, на какой из сервисов перекидывать запрос.
> Вот у вас есть два сервиса, каждый из
> которых считает что он в корне сайта, и формирует URL на свои кнопки
> как /images/something.gif.
>
> Вот приходит к вам на прокси запрос GET /images/something.gif.
>
> Как вы определите, его надо переписывать
> на /service1/images/something.gif
> или на /service2/images/something.gif?
>
Да, про это я в курсе. Вообще, сделать это может и возможно. Я даже
смутно представляю, как с костылями в виде общего cookies для всех
сервисов, но это извращение.
>> к /bla/bla/... на BASE_URL/bla/bla/...
>>
>>> Если же у нас код дошел до браузера неизменным, то браузер отправит
>>> на прокси ту URL, которую ему отдал сервер. И определить от какого
>>> из проксированных сервисов эта URL тоже будет ох как непросто.
>>>
>>> Раз задача в общем виде неразрешимая, то решать ее придется в
>>> частных случаях, для каждого из сервисов по отдельности,
>>> конфигурируя каждый сервис (если он это позволяет) на работу под
>>> уникальным префиксом, причем совпадающим с тем, что был указан нв
>>> фронтэнде.
>> Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к
>> сервисам, в которых её нет.
>>
>>>
>>>> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу
>>>> три
>>>
>>> Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный.
>>> Расходуются только строчки в файле зоны локального DNS.
>>>
>> Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP
>> через nginx это не вариант. Мне же их надо внутри держать, а запрос
>> проксировать лишь тогда, когда авторизация прошла.
>
> Почему не вариант? Вариант. Вы заводите В nginx name-based
> virtualhost, и его проксируете весь. Так что запрос
> https://externalname/static/image.gif проксируется в
> http://internalcontainerip:port/static/image.gif. Т.е. меняется при
> проксировании адрес nginx на адрес контейнера (или на localhost, если
> сервис крутится на той же машине, что и nginx. А та часть URl,которая
> следует за именем хоста - не меняется.
>
В смысле, он виден только изнутри и недоступен из внешней сети?
> Можно еще извернуться так, чтобы контейнер с сервисом считал что то
> имя, под которым вся сеть видит виртуальный хост на nginx - это его имя
>
Примерно так у меня и есть, в целом: https://habr.com/post/359344/
> Из того, что каждый сервис будет иметь свой собственный внешний
> (видимый клиентам) хостнейм, никак не следует что пользователей будут по
> этому хостнейму пускать на сервис напрямую, минуя общий для всех
> сервисов фронтенд-прокси.
>
Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним,
меня перекидывает на ещё один обратный прокси, который делает проброс
только если пользователь авторизован?
Reply to: