Тут без сабселекта не обойтись
можно вариант с сабселектом?
Илья
Alexander
Ты получишь всех у кого когда либо был статус ЗБС, а нужно что бы сейчас текущий статус был ЗБС
так он же последний, не?
Adamtsov
Можно с айди. Вопрос в том какой sql написать, что бы для каждого quest получить его последний quest_status. Для начала такой квест реши)
select quest_id from (
select quest_id, row_number() over (partition by quest_id order by status) as rownum from quest_status WHERE status = 'PROCESS'
) tmp where tmp.rownum <= 1 ;
мб вот это подойдет)
Maks
так он же последний, не?
Например у записи номер 1 последний статус НОРМ, у записи 2 последний статус ЗБС, а норм уже был. И тебе нужно получить только те, у кого сейчас НОРМ
Alexander
вообще последний статус можно и в первой таблице хранить
Maks
вообще последний статус можно и в первой таблице хранить
Это лучший вариант я думаю, я тоже к нему пришел. Либо конкретный айди статуса, либо айди из таблицы отношений на последнее отношение.
Maks
просто было интересно как это еще можно решить АДЕКВАТНО
Alexander
ты скажешь не нормализовано. так ведь в таком случае как сейчас может быть кейс, что статуса и вовсе нет, а он должен быть
Alexander
есть еще вариант. завести дату, в запросе сделать order by dt DESC, и сделать псевдо поле first_element(state) last_state. where last_state = ""
Alexander
first_element - это уже надо для субд твоей смотреть как реализовать
Alexander
есесна group by нужен
Alexander
SELECT a.id, first_element(b.status) last_status
FROM a
INNER JOIN b ON ...
GROUP BY a.id
WHERE last_status = "ЗБС"
ORDER BY b.dt DESC
Alexander
вопрос в том, что производительность может быть не огонь, если надо супер быстро
Maks
select * from quest
left join (select quest_id, max(id) as status_id
from quest_status
group by quest_id) as statuses
on quest.id = statuses.quest_id
inner join quest_status
on statuses.status_id = quest_status.id
where quest_status.status in ('PROCESS');
Maks
тут много памяти требуется конечно
Maks
и естественно просядет производительность
Maks
но можно типа так
Shakir
Shakir
Павел
🛠 Сканер портов, написанный на GO
gPScan — это простой инструмент командной строки для проверки того, открыты или закрыты определенные порты.
Чтобы установить/собрать бинарный файл, убедитесь, что у вас установлен компилятор go.
git clone https://github.com/alexpfaller/gPScan
cd gPScan
sudo make build
https://uproger.com/skaner-portov-napisannyj-na-go/
Github: https://github.com/alexpfaller/gPScan
@Golang_google
Этот простой инструмент напишет любой джун за стканчиком пива
Как по мне лучше вот это самому написать!
(у меня такие на паре языков написано)
Denis Pershin
Null
Tony
Подскажите, делаю restapi. После входа юзера, отдаю токен для последующих обращений. Как правильно потом опередить, что за юзер долбится - прошивать в токене uuid или пихать при входите токен в базу пользователей, в строку конкретного?
Anton
обычно в токене записывают id юзера или что-то в этом роде, чтобы потом накинуть мидлвару на нужные эндпоинты, где будет чекаться что юзер с токеном, а не мимокрок
ну и из токена парсить гораздо легче, чем "токен в базу пользователей", если я верно понял о чем ты
AO
JWT?
Maks
обычно в токене записывают id юзера или что-то в этом роде, чтобы потом накинуть мидлвару на нужные эндпоинты, где будет чекаться что юзер с токеном, а не мимокрок
ну и из токена парсить гораздо легче, чем "токен в базу пользователей", если я верно понял о чем ты
Ну если у тебя есть роли какие то - то в jwt шьют роли, имя пользователя (что бы на фронте можно было отображать), еще что то. Но у jwt есть ограничение на длину. Еще jwt в его классическом понимании не подходит если для себя супер важно иметь возможность оперативно менять роли, сбрасывать доступы пользователю с "других устройств" например.
Maks
Но в целом можно в jwt хранить айди пользователя и по айди лазить в базу за ролями.
Maks
в случае с ролями это более менее решение, на 1 запрос в бд меньше а иногда и вообще запросов в бд не будет (в зависимости от запроса)
Maks
А вот если нужно иметь возможность сбрасывать доступ пользователем с других устройств и что бы это было мгновенно а не после истечения токена - то тут токен уже не подойдет
Valeriy
Подскажите, делаю restapi. После входа юзера, отдаю токен для последующих обращений. Как правильно потом опередить, что за юзер долбится - прошивать в токене uuid или пихать при входите токен в базу пользователей, в строку конкретного?
jwt нужен для того, чтобы можно было не обращаться в базу каждый раз. Туда можешь зашить не приватную инфу пользователя. Например id, тип, является ли он модератором. Номер телефона зашивать нельзя, так как он является частью персональных данных. Когда поступает запрос чекаешь токен и понимаешь имеет ли пользователь доступ (например)
Anton
Ну если у тебя есть роли какие то - то в jwt шьют роли, имя пользователя (что бы на фронте можно было отображать), еще что то. Но у jwt есть ограничение на длину. Еще jwt в его классическом понимании не подходит если для себя супер важно иметь возможность оперативно менять роли, сбрасывать доступы пользователю с "других устройств" например.
да, видел, когда роли кладут в jwt
зависит от сервиса, конечно
за ограничение наверное редко кто выходит на практике, у меня по крайней мере на разных работах такого не случалось
Valeriy
Ну если у тебя есть роли какие то - то в jwt шьют роли, имя пользователя (что бы на фронте можно было отображать), еще что то. Но у jwt есть ограничение на длину. Еще jwt в его классическом понимании не подходит если для себя супер важно иметь возможность оперативно менять роли, сбрасывать доступы пользователю с "других устройств" например.
Если добавить refresh, а время жизни access уменьшить, то намана
Tony
Tony
А вот если нужно иметь возможность сбрасывать доступ пользователем с других устройств и что бы это было мгновенно а не после истечения токена - то тут токен уже не подойдет
Ну, надо что бы всегда можно было нажать выход на фронте и войти под другими учётными
Tony
Может всё-таки писать токен юзеру в базу? А то как выйти? Как у сбера, вышел и вошёл под другими учётными
Maks
Ну, надо что бы всегда можно было нажать выход на фронте и войти под другими учётными
я не об этом. Представь ты сидишь чет делаешь. В какой то момент от тебя уходит кому то спам, тебя взломали. Ты меняешь пароль, но злоумышленник всё еще имеет доступ, потому что его токен еще не истек.
Maks
что бы выйти - ты просто токен на клиенте удаляешь
Maks
и всё
Maks
И больше ты войти не можешь
Tony
Тоже тема, но пока не так важна )
Valeriy
Ну, надо что бы всегда можно было нажать выход на фронте и войти под другими учётными
Почитай про пару access и refresh токены, если что пиши, помогу с ними разобраться
Maks
Ну в целом сейчас ты можешь использовать вообще любую авторизацию.
Maks
Это вообще не важно
Maks
Я бы для начала юзал базовую авторизацию, ибо какая разница
Tony
Спасибо
Maks
разве что для spa нужно данные иметь какие то о пользователе
Maks
а потом уже можно будет любую авторизацию прикрутить
Maks
главное это делать отдельным модулем и мидлварем
Maks
что бы можно было менять способ авторизации и аутентификации не меняя код нигде кроме этого модуля
Tony
что бы можно было менять способ авторизации и аутентификации не меняя код нигде кроме этого модуля
Модулем в понимании go ?
umdnt 📻
bruh
umdnt 📻
как скажешь
Alexander
Но в целом можно в jwt хранить айди пользователя и по айди лазить в базу за ролями.
А это безопасно вообще?
Alexander
В смысле в свой токен нельзя чужой айди засунуть?
Valeriy
В смысле в свой токен нельзя чужой айди засунуть?
Смотри, вот токен eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE2NTM5OTA3NDksImlzcyI6InN0YWdlLXZpemJsIiwic3ViIjoiZjMyMDNkMTItODUxNS00OGYyLTk4ODEtN2Q0ZmYxNWI1OTcxIiwiaXNfbW9kZXIiOnRydWUsInR5cGUiOiJwcml2YXRlX3BlcnNvbiJ9.zsBFlByvXVyx0Ck4UbNPMlV9jvJeGRXGXgCDOp5qg-0
Как пример
На этом сайте ты можешь его задекодить https://jwt.io/
Чтобы посмотреть какая там инфа
Maks
В смысле в свой токен нельзя чужой айди засунуть?
Нет, у него типо контрольной суммы есть. Или типо хеша. А на сервере есть ключ по которому все проверяется.
Maks
Если ты только sha256/512 не знаешь)
Valeriy
А создать левый нельзя так как есть секрет, который знает только бэкенд
Alexander
ну айди ок. а всякие другие вещи вроде прав. инвалидировать токен, чтобы клиент попросил новый после смены каких-то данных?
Valeriy
https://www.youtube.com/watch?v=Y41nrrMcOew
Valeriy
Вот хороший видос
Alexander
типа по токену из базы меньше 1мс получить нужные данные. не проще не зашивать туда инфу, а понести такую не очень страшную жертву?
Valeriy
типа по токену из базы меньше 1мс получить нужные данные. не проще не зашивать туда инфу, а понести такую не очень страшную жертву?
Ну тут при каждом запросе тебе нужно делать запрос в бд, чтобы получить пользователя и информацию о нем
Valeriy
Evgeny
да лишняя нагрузка на всё вообще
Alexander
ну в рамках 1мс, если все работает нормально. нагрузка на чтение - не страшно. зато консистентная инфа без заморочек
Maks
ну в рамках 1мс, если все работает нормально. нагрузка на чтение - не страшно. зато консистентная инфа без заморочек
В хайлоаде критично может быть
Evgeny
да откуда 1мс-то
Maks
Плюс когда таблицы становятся все больше и больше время трже может начать расти
Evgeny
у нас что всё на одной машине крутится
Valeriy
Плюс когда таблицы становятся все больше и больше время трже может начать расти
Плюс если микросервисы, то проще посмотреть в jwt, чем делать запрос в сервис пользователей
Evgeny
в рамках одного датацентра тоже
какому-нибудь стейтлесс сервису в облаке придется коннект до базы открывать
Alexander
я уж не знаю какой страшный должен быть юзкейс когда запрос вроде
SELECT u.* FROM user u
INNER JOIN token t ON t.user_id = u.id
WHERE t.token = 'fdffsdfdsf'
был больше 1 мс