Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
А как же регистр? Юзер зарегистрировался как "vasya@gmail.com" и пытается зайти с "Vasya@gmail.com" - тоже не надо преобразовывать?
Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Нормализуйте email, добавьте соль и возьмите от этого хэш - тот же sha256 - получите заодно уникальный ключ для юзера. Можете передавать его партнёрам или писать на стене. Однако, возможна ситуация когда вы немного исправили процедуру нормализации и хэширование для уже существующих email в базе будет выдавать другой ключ. Впрочем, и без хэширования нормализованный email в базе может измениться.
По теме проверки email - как обычно, на древнем StackOverflow сохранились сокровища с примерами вроде этого. Все понимают, что надо где-то знать меру, но не все знают про эти дополнительные фичи вроде той же субадресации (RFC5233).
Однако, это уже дополнительная фича, которая может не поддерживаться почтовым сервером. Даже автор статьи в примере приводит только gmail. Однако, плюс (и минус, а также может быть и решетка #) для этого используют почти все крупные почтовые сервисы. Фича с точками - только у gmail AFAIK, но ещё могут быть корпоративные домены, которые хостятся на gmail, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
Хирург командует во время операции: - Так, приступаем к ампутации левой ноги пациента Ивано... Ассистент с пилой: <вжжжжж> Хирург: Ноги!! Ассистент с пилой: <вжжжжж> Хирург: Левой!!! - <вжжжжж>
Ну что вы к человеку пристали.. Погуглите по слову "релиденс" - найдёте 198-страничный (на данный момент) pdf-документ с названием "Физика Иного Разума".
Человек пишет свою физику. Серьёзные учёные на такое даже смотреть не будут, поэтому обычно такие теории распространяются через все подряд сайты, где, если повезёт, обрастают каким-то количеством поклонников разных теорий заговоров.
Ну правда, кто-то хочет тратить своё время и пытаться что-то доказать? Давайте наставим минусов и человек уйдёт дальше на пикабу.
Ну вот здесь уже возможны варианты. Контейнеров может быть разное количество и имена у них могут автоматически назначаться, однако кто-то может захотеть жёстко гвоздями прибить конфигурацию на именах контейнеров. Может и я захочу потом.
Лично мне нужны будут имена сервисов (как в compose или Swarm), либо, может быть, hostname - но с ними могут возникнуть сложности (особенно с разными сетями). Сервис может иметь несколько инстансов контейнеров.
Очевидно что у вас нет цели поддерживать все фичи докера, спасибо даже на тех что уже есть. В принципе, мои задачи для Swarm может решить даже обыный docker-резолвер, который в последних версиях nginx доделали.
Не совсем понял, что имеется в виду, можно чуть подробнее с примером?
Ну вот вся функциональность из labels, но только описаная в конфиге. И отключать конфигурацию из labels. Сервисы группировать либо по именам, либо по тем же labels (просто имена).
Пример конфига красивый придумать не смогу, но, вероятно, тоже что-то типа блока docker_service.
Да, будет более статическая конфигурация, но иногда это и надо. Например, никакие новые неизвестные сервисы не добавятся, конфигурация хранится и управляется в одном месте.
О, спасибо, блок client, вроде бы, вполне подходит. Я не помню такой фичи в nginx - это специфический блок, добавленный только в Angie?
Потому, что Docker API работает по HTTP-протоколу. И чтобы прочитать какой-то ответ из сокета - туда сперва нужно записать запрос.
Да, я понял ваш ответ, спасибо. А если я вместо сокета даю http ссылку на какой-то эндпоинт - ему достаточно GET запросов же? Хотелось бы в документации видеть список методов, которые нужны из API, чтобы только минимум разрешить.
Для докера - вы периодически читаете весь список контейнеров заново или подписываетесь на события? Судя по документации - второе. В таком случае - поддерживается ли Docker Swarm? Насколько я помню (не 100%) - там нет эвентов, они только для хоста.
Что если проксируемый сервис имеет более одного порта? Непонятно как метками управлять в данном случае. А если каждый порт - в отдельную docker-сеть? (этот случай - это уже что-то сложное, я не ожидаю что вы это поддерживаете, но интересно).
Как в конфиге управлять роутингом на разные порты сервиса? `location /abc/` на порт 8080, а `location /xxx/` на порт 9090 - так можно?
А можно задавать конфигурацию сервисов не через labels, а через конфиг? hot reload поддерживается же, так что можно конфиг подсовывать наживую.
У меня это всё реальные примеры. У меня Docker Swarm и сейчас у меня стоит Traefik, но он мне очень не нравится и мне бы хотелось его чем-то заменить.
Ну вот фича-то полезная (docker_endpoint), однако снова сделана немного наспех. То же самое было в Traefik v3.
Как я понимаю, Angie только читает из docker-сокета, следовательно, ему не нужен полный доступ. Чтобы его не давать - используются различные прокси-сервисы с авторизацией. Однако, авторизация здесь не поддерживается.
у пользователя, под которым запускается Angie, должны быть права чтения и записи для этого сокета
А запись-то ему зачем?
@VBart, планируется ли добавить хотя бы Basic авторизацию в эту директиву? `http://username:password@host:port ?
Ах ну простите что у вас всё наоборот. Прямо сейчас обсуждаю с клиентом переход к нему на постоянку на рабочую визу - их юристы говорят что диплом чрезвычайно желателен. Ирландия.
Им нужно как-то обосновать мою высокую зарплату и то, что я ценный специалист. У меня в активе 25 лет опыта, из которых последние 10 на фрилансе (хоть и с этим же клиентом), а остальное - три достаточно крупные компании, но все по разным причинам уже не существуют.
Наверняка без диплома тоже можно всё это устроить, но с ним проще.
На мой взгляд - всегда есть смысл развернуть что-то в Docker. Особенно на фоне борьбы автора с virtualenv и прочими пакетами - статья была бы немного короче, если дать ссылку на официальный Dockerfile.
Правда, нужно учитывать, что ваши .md-файлики именно транслируются в html, а Dockerfile настроен на то, что он запускает development-сервер, который будет эти файлики раздавать, но и на лету конвертировать только что изменённые. Возможно, лучше будет в докере просто один раз их собирать в html и раздавать через nginx как автор.
У нас, например, Github непубличный, а просить каких-нибудь продажников в нём регистрироваться чтобы дать доступ - странное решение. В Github у нас сейчас 120 репозиториев и тащить все доки из них всех нам не нужно, проще всё собрать в одном месте. Wiki из github мне лично кажется совершенно неудобным и не настраиваемым. Возможно, в gitlab оно всё как-то и лучше, но сейчас мы на него переезжать не будем точно, так что я даже сравнивать не пойду.
MkDocs поднят в контейнере на сервере во внутренней сети за VPN. Все пользователи с VPN могут иметь доступ. Кажется, даже дополнительно авторизуются через SSO, но сейчас не помню. Если нужно будет что-то разграничить - придётся придумывать ещё варианты (или искать плагины).
Заметьте - я с вами совершенно не спорю, а описываю отдельный случай когда github не является лучшим местом для доков. Ваше предложение вполне рабочее для другого случая.
Вот есть, например, такие табы для кода или заметок. Удобно - да. Нужно ли - ну не всегда.
Есть плагины для сворачивания части текста или выделения каких-то блоков отдельным цветом/заголовком (см в той же документации на страницу ниже). Удобно - да. Нужно ли - не всегда.
В целом, я поддержу статью, хотя это решение вполне может подойти не всем.
Я тоже выбрал MkDocs для внутренней документации, но у меня совсем маленькая команда - 2-4 человека.
Markdown - отдельные файлы, просто версионируются в репозитории. Если вам, например, нужно на странице видеть историю правок - можно, конечно, приделать интеграцию с git, но, наверное, лучше не нужно и лучше смотреть на тот же Confuence.
Простой синтаксис Markdown стимулирует рисовать простые странички, без таблиц третьей степени вложенности и прочих сложных элементов. Плагины есть для всего, но, опять же, если хочется чего-то сложнее - лучше рассмотреть более сложные движки. Стили можно настраивать и html вставлять, в общем-то.
Плагинов реально дофига, и поначалу глаза просто разбегаются, хочется попробовать половину из них. Другой вопрос - насколько часто они обновляются. Ну это как любой опенсорс.
Confluence, например, тоже настраивается, но сложнее и дорого. Atlassian хочет чтобы всё было у них в облаке. Например, в онлайн-редакторе Jira постоянно вылезают какие-то баннеры и подсказки, что реально раздражает. И внешний вид настроить под себя довольно сложно, не говоря уж о том чтобы синтаксис MD немного расширить..
Ну тогда мы снова вступаем на скользкую дорожку - разные ли пользователи "Vasya" и "vasya"? Тут проблема с плюсом уже - частный случай.
Но я ни разу не встречал сервиса где такое разрешалось. Наверное и правильно.
Так а пользователя-то как находить в базе при логине? Это же один аккаунт. Пароль тут совсем не при чём. Вопрос в том - как хранить email в базе.
А как же регистр? Юзер зарегистрировался как "vasya@gmail.com" и пытается зайти с "Vasya@gmail.com" - тоже не надо преобразовывать?
Нормализуйте email, добавьте соль и возьмите от этого хэш - тот же sha256 - получите заодно уникальный ключ для юзера. Можете передавать его партнёрам или писать на стене. Однако, возможна ситуация когда вы немного исправили процедуру нормализации и хэширование для уже существующих email в базе будет выдавать другой ключ. Впрочем, и без хэширования нормализованный email в базе может измениться.
По теме проверки email - как обычно, на древнем StackOverflow сохранились сокровища с примерами вроде этого. Все понимают, что надо где-то знать меру, но не все знают про эти дополнительные фичи вроде той же субадресации (RFC5233).
Однако, это уже дополнительная фича, которая может не поддерживаться почтовым сервером. Даже автор статьи в примере приводит только gmail. Однако, плюс (и минус, а также может быть и решетка #) для этого используют почти все крупные почтовые сервисы. Фича с точками - только у gmail AFAIK, но ещё могут быть корпоративные домены, которые хостятся на gmail, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
Хирург командует во время операции:
- Так, приступаем к ампутации левой ноги пациента Ивано...
Ассистент с пилой: <вжжжжж>
Хирург: Ноги!!
Ассистент с пилой: <вжжжжж>
Хирург: Левой!!!
- <вжжжжж>
and my friend's name is Semen.
Ну что вы к человеку пристали.. Погуглите по слову "релиденс" - найдёте 198-страничный (на данный момент) pdf-документ с названием "Физика Иного Разума".
Человек пишет свою физику. Серьёзные учёные на такое даже смотреть не будут, поэтому обычно такие теории распространяются через все подряд сайты, где, если повезёт, обрастают каким-то количеством поклонников разных теорий заговоров.
Ну правда, кто-то хочет тратить своё время и пытаться что-то доказать? Давайте наставим минусов и человек уйдёт дальше на пикабу.
Ну вот здесь уже возможны варианты. Контейнеров может быть разное количество и имена у них могут автоматически назначаться, однако кто-то может захотеть жёстко гвоздями прибить конфигурацию на именах контейнеров. Может и я захочу потом.
Лично мне нужны будут имена сервисов (как в compose или Swarm), либо, может быть, hostname - но с ними могут возникнуть сложности (особенно с разными сетями). Сервис может иметь несколько инстансов контейнеров.
Очевидно что у вас нет цели поддерживать все фичи докера, спасибо даже на тех что уже есть. В принципе, мои задачи для Swarm может решить даже обыный docker-резолвер, который в последних версиях nginx доделали.
Ну вот вся функциональность из labels, но только описаная в конфиге. И отключать конфигурацию из labels. Сервисы группировать либо по именам, либо по тем же labels (просто имена).
Пример конфига красивый придумать не смогу, но, вероятно, тоже что-то типа блока
docker_service.Да, будет более статическая конфигурация, но иногда это и надо. Например, никакие новые неизвестные сервисы не добавятся, конфигурация хранится и управляется в одном месте.
О, спасибо, блок client, вроде бы, вполне подходит. Я не помню такой фичи в nginx - это специфический блок, добавленный только в Angie?
Да, я понял ваш ответ, спасибо. А если я вместо сокета даю http ссылку на какой-то эндпоинт - ему достаточно GET запросов же? Хотелось бы в документации видеть список методов, которые нужны из API, чтобы только минимум разрешить.
Для докера - вы периодически читаете весь список контейнеров заново или подписываетесь на события? Судя по документации - второе. В таком случае - поддерживается ли Docker Swarm? Насколько я помню (не 100%) - там нет эвентов, они только для хоста.
Что если проксируемый сервис имеет более одного порта? Непонятно как метками управлять в данном случае. А если каждый порт - в отдельную docker-сеть? (этот случай - это уже что-то сложное, я не ожидаю что вы это поддерживаете, но интересно).
Как в конфиге управлять роутингом на разные порты сервиса? `location /abc/` на порт 8080, а `location /xxx/` на порт 9090 - так можно?
А можно задавать конфигурацию сервисов не через labels, а через конфиг? hot reload поддерживается же, так что можно конфиг подсовывать наживую.
У меня это всё реальные примеры. У меня Docker Swarm и сейчас у меня стоит Traefik, но он мне очень не нравится и мне бы хотелось его чем-то заменить.
Ну а вдруг вы пропадёте? А военкомату нужно будет у вас уточнить что-нибудь?
Я читаю это так - самокаты тоже будут сливать информацию о перемещениях известно куда.
Как у них сервера не лопнут от такого количества данных?
Ссылка: Леонид Каганов, "Законопроект"
Ну вот фича-то полезная (docker_endpoint), однако снова сделана немного наспех. То же самое было в Traefik v3.
Как я понимаю, Angie только читает из docker-сокета, следовательно, ему не нужен полный доступ. Чтобы его не давать - используются различные прокси-сервисы с авторизацией. Однако, авторизация здесь не поддерживается.
А запись-то ему зачем?
@VBart, планируется ли добавить хотя бы Basic авторизацию в эту директиву? `
http://username:password@host:port?По некоторым данным, авторство текста принадлежит тоже упомянутому здесь Лео Каганову.
Ах ну простите что у вас всё наоборот. Прямо сейчас обсуждаю с клиентом переход к нему на постоянку на рабочую визу - их юристы говорят что диплом чрезвычайно желателен. Ирландия.
Им нужно как-то обосновать мою высокую зарплату и то, что я ценный специалист. У меня в активе 25 лет опыта, из которых последние 10 на фрилансе (хоть и с этим же клиентом), а остальное - три достаточно крупные компании, но все по разным причинам уже не существуют.
Наверняка без диплома тоже можно всё это устроить, но с ним проще.
На мой взгляд - всегда есть смысл развернуть что-то в Docker. Особенно на фоне борьбы автора с virtualenv и прочими пакетами - статья была бы немного короче, если дать ссылку на официальный Dockerfile.
Правда, нужно учитывать, что ваши
.md-файлики именно транслируются в html, а Dockerfile настроен на то, что он запускает development-сервер, который будет эти файлики раздавать, но и на лету конвертировать только что изменённые. Возможно, лучше будет в докере просто один раз их собирать в html и раздавать через nginx как автор.У нас, например, Github непубличный, а просить каких-нибудь продажников в нём регистрироваться чтобы дать доступ - странное решение. В Github у нас сейчас 120 репозиториев и тащить все доки из них всех нам не нужно, проще всё собрать в одном месте. Wiki из github мне лично кажется совершенно неудобным и не настраиваемым. Возможно, в gitlab оно всё как-то и лучше, но сейчас мы на него переезжать не будем точно, так что я даже сравнивать не пойду.
MkDocs поднят в контейнере на сервере во внутренней сети за VPN. Все пользователи с VPN могут иметь доступ. Кажется, даже дополнительно авторизуются через SSO, но сейчас не помню. Если нужно будет что-то разграничить - придётся придумывать ещё варианты (или искать плагины).
Заметьте - я с вами совершенно не спорю, а описываю отдельный случай когда github не является лучшим местом для доков. Ваше предложение вполне рабочее для другого случая.
Если хватает базового Markdown - то можно и в gitlab.
Но обычно всегда хочется чего-то ещё. Вот пример из официальной документации FastAPI.
Вот есть, например, такие табы для кода или заметок. Удобно - да. Нужно ли - ну не всегда.
Есть плагины для сворачивания части текста или выделения каких-то блоков отдельным цветом/заголовком (см в той же документации на страницу ниже). Удобно - да. Нужно ли - не всегда.
В целом, я поддержу статью, хотя это решение вполне может подойти не всем.
Я тоже выбрал MkDocs для внутренней документации, но у меня совсем маленькая команда - 2-4 человека.
Markdown - отдельные файлы, просто версионируются в репозитории. Если вам, например, нужно на странице видеть историю правок - можно, конечно, приделать интеграцию с git, но, наверное, лучше не нужно и лучше смотреть на тот же Confuence.
Простой синтаксис Markdown стимулирует рисовать простые странички, без таблиц третьей степени вложенности и прочих сложных элементов. Плагины есть для всего, но, опять же, если хочется чего-то сложнее - лучше рассмотреть более сложные движки. Стили можно настраивать и html вставлять, в общем-то.
Плагинов реально дофига, и поначалу глаза просто разбегаются, хочется попробовать половину из них. Другой вопрос - насколько часто они обновляются. Ну это как любой опенсорс.
Confluence, например, тоже настраивается, но сложнее и дорого. Atlassian хочет чтобы всё было у них в облаке. Например, в онлайн-редакторе Jira постоянно вылезают какие-то баннеры и подсказки, что реально раздражает. И внешний вид настроить под себя довольно сложно, не говоря уж о том чтобы синтаксис MD немного расширить..