« Rev
@golangl   232
Fwd »


Alexander
И в сессии Битрикса лежали пароли юзверей
Maks
роли чувствительные данные
По этому в системе где есть роли они хранятся в жвт, что бы можно было проверять доступ к роутам и функциям без нагрузки на БД. Иначе смысла в жвт не будет
Maks
Если используется жвт
Alexander
А это был гос заказчик, хоть и не очень большой)
Maks
а не проще получить актуальные роли пользователя через запрос?
Тогда смысла в жвт нет. Жвт придумали что бы снизить нагрузку на бд. Если токен валиден, значит роли пользователя тоже валидны. Значит запрашивать роли юзера из бд не нужно. Иначе каждый запрос будет делать сначала запрос ролей, потом бизнес логика, потом запрос данных
Maks
иначе - "мы назначили вам права, перезайдите" - ну мне не нравиться так
Это проблема жвт, что пока токен валиден - его роли будут такими как в токене. Его нельзя сбросить, его нельзя изменить. По этому когда есть система ролей и их нужно супер пупер контролировать - используют кастомное подобие сессий.
Maks
С редисами и вот этим вот всем
John
Тогда смысла в жвт нет. Жвт придумали что бы снизить нагрузку на бд. Если токен валиден, значит роли пользователя тоже валидны. Значит запрашивать роли юзера из бд не нужно. Иначе каждый запрос будет делать сначала запрос ролей, потом бизнес логика, потом запрос данных
не токен валиден, а его подпись, верна подпись - значит можно верить данным. токен - это какието данные и подпись для этих данных. по мне, так JWT - это контейнер с данными и хэш-суммой и все что мы имеет - это то, что можно доверять этим данным, никакой секьюрности контейнер данных с хэш-суммой и только
John
роли в JWT - не думаю что это хорошая идея
John
роли хранить в сессии - не думаю что это хорошая идея
John
ИМХО
John
я предпочту нагрузку на БД, чем дыру в безопасности
John
по ролям можно выбрать жертву и уже целенаправлено работать на конкретного пользователя
Maks
роли хранить в сессии - не думаю что это хорошая идея
Сессия это просто ключ криптографический. А роди хранятся в редисе. Точнее необходимые системе данные о пользователе. И ты можешь удалить токены юзера из системы что бы сбросить некоторые сессии. Ты можешь изменить роли *на ходу*. Хранение ролей в сессии не делает токен не безопасным. Ты ведь не хранишь там пароль.
Maks
я предпочту нагрузку на БД, чем дыру в безопасности
Ты просто не представляешь разницу между 300 тысяч и 600 тысяч запросов в бд в минуту)
Maks
Тебе нужно будет масштабироваться из за твоих хотелок отказаться от такой оптимизации
Bagasl
Кстати, раз такая пьянка. К примеру есть эндпоинт и у разных ролей допустимы разные параметры (к примеру одни могут запрашивать заказы только за последний день, другие за месяц и тд). Эндпоинтов с кастомными параметрами несколько. Как лучше всего реализовать фильтрацию доступов по ролям, чтобы не писать в каждом эндпоинте свою логику?
Maks
Ну эндпоинт у тебя принимает одни и те же параметры не зависимо от роли. Тебе наверное нужно написать валидаторы просто
Maks
Проверять что запрос валидный
Maks
В зависимости от ролей
Maks
Тогда у тебя внутрянка будет общая, а вот валидатор будет не корректные запросы возвращать
Maks
Как вариант
John
Хранение ролей в сессии не делает токен не безопасным. Ты ведь не хранишь там пароль - чем длиннее сообщение, тем проще его расшифровать single responsibility: на каждую хотелку свой эндпоинт, http/2 сгладит расходы
John
300к/600к - это когда пытаешься получить весь профиль пользователя?
John
или on-demand?
John
Хранение ролей в сессии не делает токен не безопасным. Ты ведь не хранишь там пароль - хотя есть у вас RBAC здорового человека, но и передаваемые данные тоже малы
Maks
300к/600к - это когда пытаешься получить весь профиль пользователя?
Это когда роли пользователя в жвт есть и когда ролей в жвт нет. Соответственно запрос на проверку доступа к роуту у пользователя по ролям или по правам либо будет требовать сделать запрос в бд либо нет
Bagasl
Тогда у тебя внутрянка будет общая, а вот валидатор будет не корректные запросы возвращать
Не совсем понял. Я пока сделал проверку доступа к эндпоинту на уровне middleware. То есть может ли эта роль впринципе на такой эндпоинт кинуть запрос с таким методом. А потом внутри каждого хендлера валидирую параметры, с которыми пришел запрос. Если интервал слишком большой - срезаю на макс допустимый к примеру. Но такой подход мне очень не нравится
Maks
Не совсем понял. Я пока сделал проверку доступа к эндпоинту на уровне middleware. То есть может ли эта роль впринципе на такой эндпоинт кинуть запрос с таким методом. А потом внутри каждого хендлера валидирую параметры, с которыми пришел запрос. Если интервал слишком большой - срезаю на макс допустимый к примеру. Но такой подход мне очень не нравится
Ну тут тоже зависит от требований. Если ты хочешь сказать пользователю что запрос с его параметрами не валидный - то я бы сделал валидатор. Если ты хочешь просто сделать его запрос максимально корректным - то нужно сделать что то другое. В любом случае придется проверку делать по ролям. У тебя же если мидлвар уже знает роли юзера то наверняка они где то хранятся в стеке запроса. Я не до конца понимаю в чем вопрос тогда
Maks
Если возвращать ошибку то это удобнее сделать через какой то валидатор параметров. В случае чего возвращать ошибку пользователю. Тебе же в любом случае нужно делать проверку на параметры, и ничего ты тут сверх универсального не придумаешь наверное
Bagasl
Ну да, я искал именно какой-то более универсальный подход, так как часть правил фильтрования параметров одинаковая, часть уникальная для эндпоинта
Возможно попробую унифицировать общие параметры и вынести в функцию-валидатор, а уникальные ручками в каждом хендлере
Maks
верно я понимаю, что в JWT запихиваешь весь профиль пользователя?
Только полезные данные. Которые нужны каждый запрос. Ну или почти каждый. Роли одни из таких данных.
John
а нах вам тогда JWT
John
а нах вам тогда JWT
почему бы просто не гонять зашифрованный контейнер?
Maks
Я не говорю что я использую где зачем и почему. Я говорю что в ЖВТ писать роли это нормально. Это позволяет снизить нагрузку на бд. Какая разница что ты там будешь гонять и как. Про какой контейнер ты говоришь?
Maks
Этот контейнер будет где то храниться на сервере? Если да то где?
Maks
Ты не понимаешь видимо, что эти данные нужны на сервере с гораздо большей важностью, чем на клиенте.
Maks
Жвт позволяет подтвердить их валидность на сервере без необходимости лазить в бд
Maks
Но тут у жвт есть недостатки.
Maks
И тогда мы используем сгенерированный токен просто, не жвт, по которому на сервере можем идентифицировать клиента. Можем получить его роли, его права, еще что то, без обращения бд, используя только инмемори
Maks
Это решает проблему с синхронизацией изменений при использовании жвт
John
Жвт позволяет подтвердить их валидность на сервере без необходимости лазить в бд
тогда я действительно не понимаю: кто является инициатором бизнес-логики, пользователь или как?
John
Жвт позволяет подтвердить их валидность на сервере без необходимости лазить в бд
верно я понимаю, что сервис который выдаёт JWT работает с той же БД, что и сервис, который реализует бизнес-логику?
Anonymous
вопросик такой
Anonymous
зачем рефреш токен если можно юзать аксесс токен
Anonymous
типо постоянно генерить аксесс токен же лучше(в плане безопастности) он живет меньше и шанс hijacked-a будет меньше
Emil
не знаете, в чем может быть проблема, я могу много раз найти и получить десятки файлов, но если он 1 (редко 2), то invalid memory address or nil pointer dereference (при этом его можно найти, если он будет не один)
Alexander
на какой строчке?
Emil
если один файл в базе, то Reader: files[0].Body (немного выделена на фото) Когда редко их больше чем 1, то та же по смыслу, но ниже в цикле
Alexander
так у тебя Body nil там наверное
Anonymous
а это правильно, что ты не обрабатываешь ошибки когда бот посылает данные?
Anonymous
мне кажется там ошибка
Alexander
я не знаю как апи работает, но я бы с этого начал проверять
Alexander
того с чем работаешь))
Emil
а, ну драйва
Emil
Странно это конечно как-то, наверное запрещу получать файлы по одному)
Alexander
и я кста не понял, чем у тебя случай для одного и нескольких отличается
Alexander
точно error нигде не скипаешь?
Emil
и я кста не понял, чем у тебя случай для одного и нескольких отличается
в коде? В процессе дебага выделил, так смысла нет
Emil
точно error нигде не скипаешь?
только на стороне телеги) До отправки все проверяются
Алина 🪐
Здравствуйте! Разыскиваеься ментор/репетитор по golang, JavaScript и nodeJS Формат: удаленно Зарплатная вилка: 20-50к рублей за месяц. 8-10 занятий в месяц, 1-2 раза в неделю. Нужен опытный человек, который может выступить в роли учителя по golang, шарил в JavaScript и node.js Важно, чтобы человек был максимально спокойным и стрессоустойчивым. Задача такая: обучить человека азам этих языков, дать старт в работе с ними, чтобы он далее мог без проблем работать над своим проектом. Контакт для связи: @Evrgdn
Emil
так у тебя Body nil там наверное
Было забавно, что как раз если нет файлов, то так и пишет, но на одном пустое тело Но я сделал проверку на пустоту и теперь даже один файл ловит...
Null
Создание кластера сервисов в Golang с использованием HashiCorp Memberlist https://uproger.com/sozdanie-klastera-servisov-v-golang-s-ispolzovaniem-hashicorp-memberlist/ @Golang_google
Игорь
Господа, приветствую. Подскажите, почему выводятся запятые, если в принте они в роли границ между командами
Игорь
число 12.12 не подходит Вот такой выход должен быть
Emil
Первый аргумент это строка для форматирования, куда в плейсхолдеры ставятся следующие аргументы, в первой строке-аргументе запятые это часть самой строки, а не разделители, их можно убрать. Можно погуглить форматированных выводы или документацию printf
Игорь
Вот это сейчас и читаю, и практикую.. "Можно погуглить форматированных выводы или документацию printf" Я не понял в чём ошибка, можешь перефразировать?
Игорь
Если просто убрать запятые - убирал, не компилируестся
Игорь
« Rev
@golangl   232
Fwd »