Re: Доступ к медиатеке
On Sat, 6 Oct 2018 21:15:36 +0300 artiom wrote: > > Интересно, какие по вашему мнению способы использования данных > > гуглем хуже таржетированной рекламы? > > > > Не секрет, как они используют данные и какие: > https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in > > Одна из проблем, которую уже освещали, не таргетированная реклама, а > таргетированный контент. Вплоть до того, что некто может не узнать > важных новостей по своему запросу. Согласен, таргетированный контент хуже таргетированной рекламы. Поэтому я использую по умолчанию в качестве поисковой машины duckduckgo, а не google. > Потом, ещё это: "Иногда мы получаем запросы на доступ к данным > пользователя от правоохранительных органов. Наши юристы рассматривают > каждый запрос и отвечают отказом, если он составлен в слишком общих > терминах или с нарушением юридических норм." > > Рассматривают и предоставляют. Как известно, законы везде разные. У гугля есть регулярно публикуемые transparency report-ы, где они указывают количество запросов от правоохранительных органов и количество удовлетворенных среди них. С разбивкой по странам. > > Плюс, ваши данные потенциально могут утечь: > https://tproger.ru/news/facebook-87-million-leak/ > > Если возможно на Facebook, то почему не в гугле? К тому же, > google.docs были недавно яндексом проиндексированы. В данном случае (мы же обсуждали проблему попадания некоего нашего публичного сайта в поисковый индекс гугля) это нерелевантно. В случае использования Google Docs и Google Drive тут риски все те же, что и в любых облаках. Правда, размер имеет значение. В случае возникновения у гугля конфликта с роскомнадзором проблема, скорее всего, будет быстро решена. Вот они уже и с китайцами договорились, хотя несколько лет бодались. С другой стороны поломать всем известный гугль пытается куда большее количество хакеров чем какую-то никому не известную инсталляцию ownCloud. --
Re: Доступ к медиатеке
06.10.2018 20:39, Victor Wagner пишет: > On Sat, 6 Oct 2018 15:49:18 +0300 > artiom wrote: > > >> >> Т.е., всё-таки на первое место выходит доступность, а >> конфиденциальность данных на втором, и они не сильно чувствительны к >> этой угрозе? > > > Проблема тут не в том, сильно ли чувствительны данные к угрозам > конфиденциальности, а в том что разные данные к ним чувствительны очень > по разному. > > Нарушая фидошную традицию и вспоминая, что написано в subj, а там > написано "Доступ к медиатеке", мы можем рассмотреть угрозы > конфиденциальности для данных медиатеки. > > В медиатеке у нас лежат данные, которые вообще в принципе опубликованы, > и которые потенциальному атакующему доступны и из другого места. > Да не, с медиатекой всё понятно. > Но, в мире есть такая штука как копирайт, поэтому если мы вообще не > будем защищать медиатеку от несанкционированного доступа, мы можем > налететь на обвинение в незаконном распространении охраняемых > копирайтом произведений. > > Насколько я понимаю, закрытие любой самой примитивной аутентификацией > во-первых отсекает 100% ботов, которые рыщут по интернету в поисках > нелегальных копий копирайченной продукции, во-вторых, является > достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы > данные не распространяем, мы их для собственных нужд на этом сервере > держим. И даже доступом к нему не торгуем. А так все это добросовестно > приобретенные фильмы. > > Ну и вообще надо вспомнить третий тип угроз - кроме доступности и > конфиденциальности атакующий может попытаться нарушить целостность > данных. То есть стереть и/или подменить то, что он стирать или > подменять не имел права. > > Поскольку в соседнем письме речь шла о нескольких пользователях, > которым предлагается дать права на удаление/изменение данных, тут дать > единого рецепта на все случаи жизни, пожалуй не получится - сначала > роспись того, какие у нас бывают пользователи и над какими данными они > имеют власть, а потом модель угроз. > Это часть модели. Но в явном виде у меня её нет. В общем-то задача состоит в том, чтобы давать разный доступ разным группам так, чтобы это было удобно. >>> Потому что первым в списке угроз "будет плохо, если они прочитают >>> ваши данные" стоит гугль, который использует данные для >>> таржетированной рекламы. И при этом существует достаточно много >>> данных, которые их владельцы старательно скармливают гуглю, чтобы >>> они попали в результаты поиска. >>> >> >> Он использует эти данные не только для рекламы. >> > Интересно, какие по вашему мнению способы использования данных гуглем > хуже таржетированной рекламы? > Не секрет, как они используют данные и какие: https://privacy.google.com/intl/ru/take-control.html?categories_activeEl=sign-in Одна из проблем, которую уже освещали, не таргетированная реклама, а таргетированный контент. Вплоть до того, что некто может не узнать важных новостей по своему запросу. Потом, ещё это: "Иногда мы получаем запросы на доступ к данным пользователя от правоохранительных органов. Наши юристы рассматривают каждый запрос и отвечают отказом, если он составлен в слишком общих терминах или с нарушением юридических норм." Рассматривают и предоставляют. Как известно, законы везде разные. Плюс, ваши данные потенциально могут утечь: https://tproger.ru/news/facebook-87-million-leak/ Если возможно на Facebook, то почему не в гугле? К тому же, google.docs были недавно яндексом проиндексированы. И есть немало компаний и "аффилированных лиц", которым гугл передаёт данные.
Re: Доступ к медиатеке
On Sat, 6 Oct 2018 15:49:18 +0300 artiom wrote: > > Т.е., всё-таки на первое место выходит доступность, а > конфиденциальность данных на втором, и они не сильно чувствительны к > этой угрозе? Проблема тут не в том, сильно ли чувствительны данные к угрозам конфиденциальности, а в том что разные данные к ним чувствительны очень по разному. Нарушая фидошную традицию и вспоминая, что написано в subj, а там написано "Доступ к медиатеке", мы можем рассмотреть угрозы конфиденциальности для данных медиатеки. В медиатеке у нас лежат данные, которые вообще в принципе опубликованы, и которые потенциальному атакующему доступны и из другого места. Но, в мире есть такая штука как копирайт, поэтому если мы вообще не будем защищать медиатеку от несанкционированного доступа, мы можем налететь на обвинение в незаконном распространении охраняемых копирайтом произведений. Насколько я понимаю, закрытие любой самой примитивной аутентификацией во-первых отсекает 100% ботов, которые рыщут по интернету в поисках нелегальных копий копирайченной продукции, во-вторых, является достаточно хорошей отмазкой в случае если наезд таки произойдет. Мы данные не распространяем, мы их для собственных нужд на этом сервере держим. И даже доступом к нему не торгуем. А так все это добросовестно приобретенные фильмы. Ну и вообще надо вспомнить третий тип угроз - кроме доступности и конфиденциальности атакующий может попытаться нарушить целостность данных. То есть стереть и/или подменить то, что он стирать или подменять не имел права. Поскольку в соседнем письме речь шла о нескольких пользователях, которым предлагается дать права на удаление/изменение данных, тут дать единого рецепта на все случаи жизни, пожалуй не получится - сначала роспись того, какие у нас бывают пользователи и над какими данными они имеют власть, а потом модель угроз. > > Потому что первым в списке угроз "будет плохо, если они прочитают > > ваши данные" стоит гугль, который использует данные для > > таржетированной рекламы. И при этом существует достаточно много > > данных, которые их владельцы старательно скармливают гуглю, чтобы > > они попали в результаты поиска. > > > > Он использует эти данные не только для рекламы. > Интересно, какие по вашему мнению способы использования данных гуглем хуже таржетированной рекламы?
Re: nginx и проксирование
On Sat, 6 Oct 2018 17:56:30 +0300 artiom wrote: d > > Из того, что каждый сервис будет иметь свой собственный внешний > > (видимый клиентам) хостнейм, никак не следует что пользователей > > будут по этому хостнейму пускать на сервис напрямую, минуя общий > > для всех сервисов фронтенд-прокси. > > > > Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним, Не домена, а хоста. И все их A-записи указывают на один и тот же IP-адрес - тот, на котором nginx. В конфиге у nginx пишем, что если к нему пришли, указав в http запросе такой-то хостнейм, проксируем на такой-то сервис. Обратная прокси будет одна. И слушать будет на одном IP-адресе и одном порту. Просто в этот IP-адрес будет резолвится несколько имен, и на основании того имени, к которому обратился клиент (и честно указал это в HTTP запросе, как это позволяет HTTP/1.0 и безусловно требует HTTP/1.1) nginx будет решать куда именно проксировать прошедший авторизацию запрос. Просто вы тут разработали систему, когда признаком того, к какому сервису относится запрос, является префикс пути, а я предлагаю использовать для этого другую часть URL - имя хоста. > меня перекидывает на ещё один обратный прокси, который делает проброс > только если пользователь авторизован? >
Re: nginx и проксирование
06.10.2018 13:46, Victor Wagner пишет: > On Sat, 6 Oct 2018 12:56:42 +0300 > artiom wrote: > >> 05.10.2018 22:54, Victor Wagner пишет: >>> В Fri, 5 Oct 2018 22:32:47 +0300 >>> artiom пишет: >>> Да, 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/ > Из того, что каждый сервис будет иметь свой собственный внешний > (видимый клиентам) хостнейм, никак не следует что пользователей будут по > этому хостнейму пускать на сервис напрямую, минуя общий для всех > сервисов фронтенд-прокси. > Хм... Т.е., я завожу в своей зоне ещё три домена. При обращении к ним, меня перекидывает на ещё один обратный прокси, который делает проброс только если пользователь авторизован?
Re: Доступ к медиатеке
А причём здесь вообще телеграм? 06.10.2018 16:01, Евгений Кабанов пишет: >> Впрочем, несколько ушли от темы доступа к медиатеке. >> Музыка и фильмы - это явно не те данные, которые я хочу защитить ото >> всех. Мне нужно предоставить доступ на запись/изменение с аудитом для >> некоторых авторизованных людей. >> И на чтение для большинства авторизованных. >> Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на >> практике. >> Может имеются ещё варианты? > > Есть простые, но возможно не правильные решения: > 1. грузите контент в приватный канал телеги; > 2. назначаете админов с нужными правами (на изменение); > 3. просто подписываете всех остальных, кого решите; > 4. поддерживаете состав подписчиков и админов в соответствии с > собственной политикой. >
Re: Доступ к медиатеке
D. H. -> debian-russian@lists.debian.org @ Sat, 6 Oct 2018 06:18:14 -0500: > On 06/10/18 05:53 AM, Victor Wagner wrote: >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с >> телеграмовской прокси. > Вот это я пошел гуглить. Что-то пропустил похоже. Угу. Пару месяцев назад, подыскивая для машинки на DigitalOcean адрес, не заблокированный Роскомнадзором, я перебрал пять их датацентров. С трудом нашел.
Re: Доступ к медиатеке
> Впрочем, несколько ушли от темы доступа к медиатеке. > Музыка и фильмы - это явно не те данные, которые я хочу защитить ото > всех. Мне нужно предоставить доступ на запись/изменение с аудитом для > некоторых авторизованных людей. > И на чтение для большинства авторизованных. > Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на > практике. > Может имеются ещё варианты? Есть простые, но возможно не правильные решения: 1. грузите контент в приватный канал телеги; 2. назначаете админов с нужными правами (на изменение); 3. просто подписываете всех остальных, кого решите; 4. поддерживаете состав подписчиков и админов в соответствии с собственной политикой. -- Евгений Кабанов
Re: Доступ к медиатеке
Впрочем, несколько ушли от темы доступа к медиатеке. Музыка и фильмы - это явно не те данные, которые я хочу защитить ото всех. Мне нужно предоставить доступ на запись/изменение с аудитом для некоторых авторизованных людей. И на чтение для большинства авторизованных. Сейчас пока думаю насчёт webdav с LDAP, чуть позже займусь на практике. Может имеются ещё варианты? 04.10.2018 20:44, artiom пишет: > Требуется организовать доступ к медиатеке, позволяющий нескольким > пользователям переименовывать, удалять и, главное, добавлять файлы. > > Медиатеку показываю, используя Emby, но с добавлением там всё плохо, а о > полноценном управлении, как файловой структурой, и говорить нечего. > > При этом, условие такого, что пользователи авторизуются через LDAP. > > Один из вариантов был - использовать файловые менеджеры в > докер-контейнере, типа sprut.io, но с LDAP там всё плохо. > Ещё один вариант, который я серьёзно рассматривал - использовать sshfs и > системный pam-ldap модуль. Но встали вопросы: как не дать пользователю > выполнять команды и ограничить просмотр дерева не выше того каталога, в > котором хранится медиатека? > > Есть какие-то варианты того, как эту задачу решают белые люди? > Что посоветуете? > И по pam-ldap вопросы тоже актуальны. >
Re: Доступ к медиатеке
06.10.2018 13:53, Victor Wagner пишет: > On Sat, 6 Oct 2018 12:59:41 +0300 > artiom wrote: > >> 05.10.2018 23:06, D. H. пишет: >>> On 05/10/18 02:45 PM, artiom wrote: А от кого вы защищаться собрались? >>> >>> Как правильно было сказано уже не помню где. Но суть примерно такая: >>> >>> - Вам есть что скрывать? >>> - Нет, но мои данные не ваше дело. >>> >> Не в тему. >> Вопрос совершенно конкретный: "От кого вы собрались защищаться?" >> Если вы этого не понимаете, то как вы определите перечень мер защиты? > > Защищаться надо > > 1. От пьяного тракториста, который переедет интернет кабель > 2. От обкурившегося сетевого админа, который сломает роутинг. > 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако > может случайно попасть под раздачу, оказавшись в одном /16 блоке с > телеграмовской прокси. > 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. > > От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные. > Т.е., всё-таки на первое место выходит доступность, а конфиденциальность данных на втором, и они не сильно чувствительны к этой угрозе? > 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. > Какая "прелесть". > Определить от каких угроз несанкционированного доступа следует защищать > данные, практически невозможно, если не знать характера данных. > Конечно. Я о том и говорю. Когда вы будете думать, надо ли защищаться и от кого, вопрос о характере данных встанет. > Потому что первым в списке угроз "будет плохо, если они прочитают > ваши данные" стоит гугль, который использует данные для таржетированной > рекламы. И при этом существует достаточно много данных, которые их > владельцы старательно скармливают гуглю, чтобы они попали в результаты > поиска. > Он использует эти данные не только для рекламы.
Re: Доступ к медиатеке
> On 06/10/18 04:59 AM, artiom wrote: >> Не в тему. > > Почему же? У вас душ к примеру на улице находиться? полностью прозрачный? > Потому что вопрос был не о душе на улице и не о философских проблемах необходимости защиты информации. >> Вопрос совершенно конкретный: "От кого вы собрались защищаться?" > > В том то и дело. Вопрос не верен. Не от кого. А почему (ну или зачем). А > ответ уже есть :) > Вопрос совершенно верен. Думаю, что эту тему я знаю несколько лучше вас. Если хотите формально: какова модель нарушителя? >> Если вы этого не понимаете, то как вы определите перечень мер защиты? > > Очень просто. Задача обеспечить конфиденциальность целостность и > доступность. > От кого? Кому? Для чего? На каком уровне? Вы говорите общими словами, а они дают мало.
Re: Доступ к медиатеке
06.10.2018 14:18, D. H. пишет: > On 06/10/18 05:53 AM, Victor Wagner wrote: >> 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако >> может случайно попасть под раздачу, оказавшись в одном /16 блоке с >> телеграмовской прокси. > > Вот это я пошел гуглить. Что-то пропустил похоже. > Совсем немного: блокировки миллионов адресов, судебные иски и срач в сторону РКН.
Re: Доступ к медиатеке
> On 06/10/18 04:58 AM, artiom wrote: >> От задач. Если вы хотите, например, имея облако, отдать файл по ссылке >> кому-то постороннему. > > Боже упаси и сохрани от хранения важной инфы в облаках. (икону наверное > надо ещё приложить) > В своём облаке. Что такое "важная инфа"? Вы как-то измеряете степень важности? >> Как вы это сделаете, если NAS доступен только через VPN? > > А я сказал только? > Ну ok, доступен через VPN для манипуляции файлами. А манипулировать ими хочу не только я. Кроме того, надо поднимать VPN на NAS, что само по себе задач не решит, лишь откроет другие пути, которые без VPN не работают. >> Вы будете всех переводить на VPN? > > Это даже телефоны умеют. В чем проблема? > В том, что это надо сделать тому, кто это делать не хочет. Это переусложнение. Вам надо поделиться с человеком данными, а вы ему не только ссылку, но "поставь VPN". > Итого: > > Это не проблема VPN, это проблема внезапно возникшего человека. У > которого нет в данный конкретный момент VPN. И с ним вопрос будет решен > индивидуально, как ему и мне удобнее. > Опять же: каковы условия? Есть пять человек, которым этот VPN нафиг не сдался. Онис гитом, например, работают. Всё по SSH, интерфейс по HTTPS. Зачем тут VPN? > Как правило таки файлы умещаются в обычный email. > > Всё остальное. Ну вопрос только к самой информации. Смотря что вы хотите > раздавать. > И это тоже: что и кому.
Re: Доступ к медиатеке
On Sat, 6 Oct 2018 12:59:41 +0300 artiom wrote: > 05.10.2018 23:06, D. H. пишет: > > On 05/10/18 02:45 PM, artiom wrote: > >> А от кого вы защищаться собрались? > > > > Как правильно было сказано уже не помню где. Но суть примерно такая: > > > > - Вам есть что скрывать? > > - Нет, но мои данные не ваше дело. > > > Не в тему. > Вопрос совершенно конкретный: "От кого вы собрались защищаться?" > Если вы этого не понимаете, то как вы определите перечень мер защиты? Защищаться надо 1. От пьяного тракториста, который переедет интернет кабель 2. От обкурившегося сетевого админа, который сломает роутинг. 3. От очередной драчки роскомнадзора с Дуровым при которой ваше облако может случайно попасть под раздачу, оказавшись в одном /16 блоке с телеграмовской прокси. 4. От bingbot-а, который запросто может устроить DoS атаку вашему сайту. От этих угроз (угроз доступности) следует защищать ЛЮБЫЕ данные. Определить от каких угроз несанкционированного доступа следует защищать данные, практически невозможно, если не знать характера данных. Потому что первым в списке угроз "будет плохо, если они прочитают ваши данные" стоит гугль, который использует данные для таржетированной рекламы. И при этом существует достаточно много данных, которые их владельцы старательно скармливают гуглю, чтобы они попали в результаты поиска.
Re: nginx и проксирование
On Sat, 6 Oct 2018 12:56:42 +0300 artiom wrote: > 05.10.2018 22:54, Victor Wagner пишет: > > В Fri, 5 Oct 2018 22:32:47 +0300 > > artiom пишет: > > > >> Да, 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? > к /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 - это его имя Из того, что каждый сервис будет иметь свой собственный внешний (видимый клиентам) хостнейм, никак не следует что пользователей будут по этому хостнейму пускать на сервис напрямую, минуя общий для всех сервисов фронтенд-прокси. --
Re: Доступ к медиатеке
05.10.2018 23:06, D. H. пишет: > On 05/10/18 02:45 PM, artiom wrote: >> А от кого вы защищаться собрались? > > Как правильно было сказано уже не помню где. Но суть примерно такая: > > - Вам есть что скрывать? > - Нет, но мои данные не ваше дело. > Не в тему. Вопрос совершенно конкретный: "От кого вы собрались защищаться?" Если вы этого не понимаете, то как вы определите перечень мер защиты?
Re: Доступ к медиатеке
06.10.2018 00:13, D. H. пишет: > On 05/10/18 02:33 PM, artiom wrote: >> VPN привносит другие проблемы, которые мне не требуются. > > Ну со мной поделитесь, я пока не столкнулся но возможно удаться избежать > этого в будущем так как буду иметь в виду и думать над потенциальным > решением. > От задач. Если вы хотите, например, имея облако, отдать файл по ссылке кому-то постороннему. Как вы это сделаете, если NAS доступен только через VPN? Вы будете всех переводить на VPN? >> Не будем спорить. > > И не собирался. >
Re: nginx и проксирование
05.10.2018 22:54, Victor Wagner пишет: > В Fri, 5 Oct 2018 22:32:47 +0300 > artiom пишет: > >> Да, nginx ни в чём, ни в чём не виноват. >> Это на странице прописано включение css от корня и браузер, >> соответственно, делает GET запрос. >> Вопрос, как сделать, не заводя корень, и возможно ли это? > > А подумать? Вот у нас есть поток данных, идущих от сервера к браузеру > через proxy. > Вот через подумать и выходит, что технически это возможно. > Вот где-то внутри этого потока данных js-код, формирующий URL запроса. > По-моему, очевидно, что прошерстить весь этот код и выловить URL, > чтобы их переписать - задача в общем виде не разрешимая. >Так и не требуется. Достаточно подменить PUT/POST/GET/etc., обращающиеся к /bla/bla/... на BASE_URL/bla/bla/... > Если же у нас код дошел до браузера неизменным, то браузер отправит на > прокси ту URL, которую ему отдал сервер. И определить от какого из > проксированных сервисов эта URL тоже будет ох как непросто. > > Раз задача в общем виде неразрешимая, то решать ее придется в частных > случаях, для каждого из сервисов по отдельности, конфигурируя каждый > сервис (если он это позволяет) на работу под уникальным префиксом, > причем совпадающим с тем, что был указан нв фронтэнде. > Ага, это при том, что я пытаюсь общую авторизацию LDAP припилить к сервисам, в которых её нет. > >> У меня уже этих доменов штук 7, а здесь не Transmission, а сразу три > > Да хоть сотня. Жалко их что ли? Этот ресурс нелимитированный. > Расходуются только строчки в файле зоны локального DNS. > Не особенно удобно. А в случае с сервисами, авторизуемыми по LDAP через nginx это не вариант. Мне же их надо внутри держать, а запрос проксировать лишь тогда, когда авторизация прошла. >> сервиса висит за LDAP авторизацией через nginx > > Вот как раз transmission прекрасно работает с указанием префикса. > > Там единственное, что нужно сделать кроме проксирования > /transmission/ это перманентный редирект /transmisson > на /transmission/web. Ok, посмотрю, как с ним разобраться. jDownloader работает тоже. Остаётся GUI к youtube-dl.
