то есть, условно, api := router.Group("/api") api.Use(MyMiddleware) api.Get("/", MyHandler)

а то немного проблематично делать так, чтобы можно было миддлвари после обработчиков указывать

в джине можно вроде добавить новую мидлварь после добавления роутов

в джине можно вроде добавить новую мидлварь после добавления роутов

ладно, тогда добавлю это в туду

ладно, тогда добавлю это в туду

туду? это же просто цепочка мидлваров, не выйдет по-другому сделать

туду? это же просто цепочка мидлваров, не выйдет по-другому сделать

цепочку мидлваров мы можем ещё на этапе регистрации обработчиков применить

привет , я хочу сделать систему который понимает что человек тонит на воде, с чего советуете начинать ?

machine learning...

цепочку мидлваров мы можем ещё на этапе регистрации обработчиков применить

условно, имеем обработчик и множество миддлварей, каждая принимает следующую миддлварь

цепочку мидлваров мы можем ещё на этапе регистрации обработчиков применить

ну для такого есть группы и роуты, если я правильно понял

и вот как-то так мы превращаем эту последовательность в просто обработчик, который уже сам внутри вызывает миддлвари

и вот как-то так мы превращаем эту последовательность в просто обработчик, который уже сам внутри вызывает миддлвари

правда, я не уверен, что это работает

ну для такого есть группы и роуты, если я правильно понял

ну, я себе это вижу так каждая дочерняя группа наследует все родительские миддлвари, но родитель ничего не знает о дочерних миддлварях при роуте, мы можем указать миддлвари для конкретного обработчика. router.Use() - это указание миддлвари для целой группы и всех дочерних групп обработчиков

я вижу это как изначально мертвый проект

ну, я себе это вижу так каждая дочерняя группа наследует все родительские миддлвари, но родитель ничего не знает о дочерних миддлварях при роуте, мы можем указать миддлвари для конкретного обработчика. router.Use() - это указание миддлвари для целой группы и всех дочерних групп обработчиков

сейчас миддлвари просто лежат в обработчике как слайс, и при каждом роуте композируется слайс для group-wide миддлварей и handler-wide

посмотрел бы как в gin сделано

сейчас миддлвари просто лежат в обработчике как слайс, и при каждом роуте композируется слайс для group-wide миддлварей и handler-wide

но планирую реализовать дополнительно в каждой группе списочек обработчиков, зарегистрированных конкретно через эту группу. И при новой миддлвари для группы, мы просто добавляем новую цепочку в композицию миддлварей

Ребят, привет. Есть те, кто работал с aws-ses?

Суть в том, что хочу реализовать reply на своё же письмо, чтобы на почте отображалась не тьма писем, а все красиво лежало в одном. Но в доке нет ничего по этому, да и примеров тоже не нашёл

так а причём тут SES

это штука общая для всех писем

следовательно нужно курить почтовые заголовки вообще

Л - логика

Товарищи, а чем паттерн хареография отличается от распределенного монолита?

у меня есть параметры пути, и я хочу, чтобы они парсились только тогда, когда они действительно нужны. То есть, у нас лежит слайс байт с этими параметрами, и если пользователь хочет получить, а у нас они не спаршены - мы их парсим, и тогда отдаём ответ но вот нюанс: что, если строка невалидна (например, заканчивается на пару без значения, даже пустого)? Как мне тогда ошибку вернуть?

ведь мы ожидаем от геттера сигнатуру аки (value []byte, found bool)

ведь мы ожидаем от геттера сигнатуру аки (value []byte, found bool)

пришёл к решению возвращать (value []byte, err error). Если не найдено, ошибка ErrNotFound

хотя, думаю, ErrNoSuchKey здесь будет более уместным, дабы не вызывать коллизий с 404 not found

когда в названиях функций используется Handle, а когда Handler?

когда в названиях функций используется Handle, а когда Handler?

Функция это глагол

когда в названиях функций используется Handle, а когда Handler?

handle в начале, handler в конце

👍

привет всем

у меня одна проблема появилась, крч, чтобы запушит в гитхаб коммити, требуется вести логин и пароль от гитхаба в терминале

но пароль не получатся вводит

тупо ничего не печатается

может кто-то сталкивался и знает как это решить?

у меня одна проблема появилась, крч, чтобы запушит в гитхаб коммити, требуется вести логин и пароль от гитхаба в терминале

У тебя 2fa настроен?

тупо ничего не печатается

А дак лол, он просто не показывает что ты печатаешь

Это нормально

В линухе всегда так

Ну тоесть пароль вводится просто hidden

Чтоб не палить количество символов

У тебя 2fa настроен?

не знаю, даже не проверил. Но у меня ОС виндовс, язык ГО

Может кто с логикой jwt помочь?

не знаю, даже не проверил. Но у меня ОС виндовс, язык ГО

Ну или используй ssh-key прост. Я уже не помню когда пароль использовал.

Ну или используй ssh-key прост. Я уже не помню когда пароль использовал.

спасибо, да придётся

Я правильно понимаю логику? Человек авторизировался, все данные валидны и я ему выдаю два токена - рефреш и аксесс. В midlware проверяю аксесс токен. Если аксесс не устарел, то пропускаю на энпоинт. Если аксесс устарел, то я проверяю рефреш токен и если рефреш токен не устарел, то даю новую пару рефреша и аксесса. Если и рефреш, и аксесс оба прошли по времени, то удаляю их из бд и человеку заново надо авторизоваться

не знаю, даже не проверил. Но у меня ОС виндовс, язык ГО

Я помню, что на винде была проблема, что она запоминает пароль и потом фиг сбросишь.

Я помню, что на винде была проблема, что она запоминает пароль и потом фиг сбросишь.

ахахахах, блен)

Я правильно понимаю логику? Человек авторизировался, все данные валидны и я ему выдаю два токена - рефреш и аксесс. В midlware проверяю аксесс токен. Если аксесс не устарел, то пропускаю на энпоинт. Если аксесс устарел, то я проверяю рефреш токен и если рефреш токен не устарел, то даю новую пару рефреша и аксесса. Если и рефреш, и аксесс оба прошли по времени, то удаляю их из бд и человеку заново надо авторизоваться

Вроде всё верно

Ну да, все ок

Кк, спасибо

Кк, спасибо

Ещё стоит идентифицировать пользователя, вдруг стянули токены.

А это как?

Токен же с куки считывать буду, идентифицировать по каким параметрам?

Давно всем этим не занимался. Первое что пришло в голову хешировать информацию о пользователе, user-agent, ещё что-то. ip меняется его не захешировать чтоб не слетела авторизация Можно время добавить туда. Ну и хранить хеш на стороне пользователя. Он его отсылает, ты проверяешь тот не тот.

Может можно его вообще в токен засунуть, но это не имеет великого смысла

https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc

Точно, это Fingerprint

https://gist.github.com/zmts/802dc9c3510d79fd40f9dc38a12bccfc

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

а есть альтернатива?

Альтернатива чему?

jwt

Куки сессии, которые проверены уже давно

Куки сессии, которые проверены уже давно

а как там предотвращают кражи? как и jwt, fingerprint

Jwt больше для краткосрочных операций подходит, где не надо заниматься инвалидацией и придумывать рефреш токены

а как там предотвращают кражи? как и jwt, fingerprint

Точно также, только не надо с токенами бороться, кладёшь в httponly, secure куку Id сессии и хранишь в бд тот же самый фингерпринт и в миддлваре проверяешь

Если например юзер агент и айпи отличаются от тех что в сессии, возвращаешь 401

И за счёт этого можешь разлогинить без проблем все сессии

Точно также, только не надо с токенами бороться, кладёшь в httponly, secure куку Id сессии и хранишь в бд тот же самый фингерпринт и в миддлваре проверяешь

на каждый запрос вызов бд

Если например юзер агент и айпи отличаются от тех что в сессии, возвращаешь 401

ну это да

Напомню, по ip 401 не ок если пользователь с телефона.

на каждый запрос вызов бд

Если важна безопасность, то скорее всего будешь делать короткие access токены по жизни, также хранить его только в памяти приложения на клиенте и в таком случае: 1. Пользователь обновил страницу, токена больше нет и надо лезть опять в базу за рефреш токеном 2. Токен протух, также лезть в базу чтобы получить рефреш Но при этом весь смысл jwt теряется когда ты хранишь рефреш токены в базе, что по сути является теми же сессиями, если надо разлогинивать пользователей, то придётся делать некий чёрный список с токенами, что тоже идёт против stateles jwt И получается что jwt не такой уже и stateful как хотелось бы и в базу ты все равно будешь ходить, не проще ли сделать куки сессии и не ограничивать себя?)

на каждый запрос вызов бд

https://www.youtube.com/watch?v=GdJ0wFi1Jyo&t=31s вот здесь намного больше инфы касаемо этого

Имхо сессии для клиент - сервер, jwt для кратковременных операций (например смена пароля или скачивание файла) и аутентификации между сервисами

Жвт может и долго жить в принципе. Единственно кража - да. Там есть свои нюансы с точки зрения безопасности. С другой стороны, можно секурные данные защищать паролем помимо жвт. И изменение данных тоже. Кейсов кучу придумать можно. Вообще жвт идеально подходит для общения между микросервисами. В одном месте клиент собрался в жвт и раскидывай этот токен между сервисами. Сервисам не нужно будет пользователя авторизовывать и что то проверять. Важная инфа зашита. Но в таком случае у всех сервисов должен быть общий ключ.

Давно всем этим не занимался. Первое что пришло в голову хешировать информацию о пользователе, user-agent, ещё что-то. ip меняется его не захешировать чтоб не слетела авторизация Можно время добавить туда. Ну и хранить хеш на стороне пользователя. Он его отсылает, ты проверяешь тот не тот.

Мак адрес наверно можно

Вроде всё верно

А можно ли сделать отдельный эндпоинт для рефреша токенов

Типо делегировать ответственность за рефреш токенов клиенту

Типо делегировать ответственность за рефреш токенов клиенту

Норм тема, клиент сможет в фоне рефрешить, чтобы если че не потерять авторизацию.

Абстрактные анонимные сети Среди анонимных сетей можно выявить класс систем максимально разграничивающих субъектов информации от их объектов, что приводит к возможности различных способов транспортирования информации. Из-за своей специфичной архитектуры передача информации может осуществляться в любой дуплексной среде, что полностью отрывает распространение объектов от своей сетевой архитектуры и переводит маршрутизацию в этап виртуального транслирования. Тем не менее у такой концепции существуют и свои недостатки, где одним из основных является невозможность построения поточной связи из-за отсутствия постоянных соединений, что в определённой степени становится уязвимостью к активным нападениям (более подробно данный момент будет показан в разделе «Модель абстрактных анонимных сетей на базе очередей»). ➡️ Читать дальше 📃 Теория скрытых систем @Golang_google