p
Подскажите, не могу понять на счет вендоринга в версии 1.14.
Я просто создаю папку vendor в корне своего проекта и перетаскиваю туда все нужные мне зависимости? Больше ничего делать не надо?
Size: a a a
2020 May 07
ОЭ
VM
Подскажите, не могу понять на счет вендоринга в версии 1.14.
Я просто создаю папку vendor в корне своего проекта и перетаскиваю туда все нужные мне зависимости? Больше ничего делать не надо?
Я просто создаю папку vendor в корне своего проекта и перетаскиваю туда все нужные мне зависимости? Больше ничего делать не надо?
Нет, вы просто читаете маны по go mod
ОЭ
Нет, вы просто читаете маны по go mod
Читал, и из-за этого все ещё менее понятным стало.
Я создал программу, не модуль. И я хочу просто обезопасить себя от изменений в зависимостях. А эти зависимости тоже не модули.
Я создал программу, не модуль. И я хочу просто обезопасить себя от изменений в зависимостях. А эти зависимости тоже не модули.
VM
При чем тут модуль не модуль 😅
J
Подскажите, планирую сделать вот такую авторизацию:
1) Юзер вводит данные для входа
2) Сверяем эти данные с данными из бд
3) Если совпдают, генерируем токен и пишем его в бд, в куки юзеру
На всех страницах, где нужна авторизация получаем токен из куки, сверяем с теми, что есть в бд
Какие минусы?
1) Юзер вводит данные для входа
2) Сверяем эти данные с данными из бд
3) Если совпдают, генерируем токен и пишем его в бд, в куки юзеру
На всех страницах, где нужна авторизация получаем токен из куки, сверяем с теми, что есть в бд
Какие минусы?
VM
Подскажите, планирую сделать вот такую авторизацию:
1) Юзер вводит данные для входа
2) Сверяем эти данные с данными из бд
3) Если совпдают, генерируем токен и пишем его в бд, в куки юзеру
На всех страницах, где нужна авторизация получаем токен из куки, сверяем с теми, что есть в бд
Какие минусы?
1) Юзер вводит данные для входа
2) Сверяем эти данные с данными из бд
3) Если совпдают, генерируем токен и пишем его в бд, в куки юзеру
На всех страницах, где нужна авторизация получаем токен из куки, сверяем с теми, что есть в бд
Какие минусы?
Хранят не данные в бд а хеш, и сверяют хеши
А вообще так и делают, в редис с ТТЛ ключ кладете и проверяете мидлварей
А вообще так и делают, в редис с ТТЛ ключ кладете и проверяете мидлварей
Н
Хранят не данные в бд а хеш, и сверяют хеши
А вообще так и делают, в редис с ТТЛ ключ кладете и проверяете мидлварей
А вообще так и делают, в редис с ТТЛ ключ кладете и проверяете мидлварей
Зачем редис сразу, можно без него
VM
Зачем редис сразу, можно без него
Потому что идеально подходит, легко реализовать + быстро работает? Велосипедисты не одобрят конечно
Н
Потому что идеально подходит, легко реализовать + быстро работает? Велосипедисты не одобрят конечно
Почему не хранить сессию в БД? Редис лишняя зависимость. + можно JWT токены
RS
Подскажите, планирую сделать вот такую авторизацию:
1) Юзер вводит данные для входа
2) Сверяем эти данные с данными из бд
3) Если совпдают, генерируем токен и пишем его в бд, в куки юзеру
На всех страницах, где нужна авторизация получаем токен из куки, сверяем с теми, что есть в бд
Какие минусы?
1) Юзер вводит данные для входа
2) Сверяем эти данные с данными из бд
3) Если совпдают, генерируем токен и пишем его в бд, в куки юзеру
На всех страницах, где нужна авторизация получаем токен из куки, сверяем с теми, что есть в бд
Какие минусы?
минусы по сравнению с чем?
VM
Почему не хранить сессию в БД? Редис лишняя зависимость. + можно JWT токены
В бд нет ттл, и оно медленнее. Если для вас 50мб оперативы в докере это смерть проекта - можно конечно и неэффективное решение применить)
RS
В бд нет ттл, и оно медленнее. Если для вас 50мб оперативы в докере это смерть проекта - можно конечно и неэффективное решение применить)
для этого можно и просто время создания сессии класть в бд, для этого необязательно redis тащить
VM
Да понятно что необязательно. Можно и на го key-val inmemory с ttl и бекапом данных устроить. Зачем только, если есть распространенный стандарт
Н
В бд нет ттл, и оно медленнее. Если для вас 50мб оперативы в докере это смерть проекта - можно конечно и неэффективное решение применить)
Добавьте поле expiration_date и проверяйте, вот и ТТЛ. Вы все равно ходите по сети, что в редис что в основную БД. Редис не выиграет существенно времени, зато добавит потенциальную точку отказа, без которой сервис работать не будет
ВС
Да понятно что необязательно. Можно и на го key-val inmemory с ttl и бекапом данных устроить. Зачем только, если есть распространенный стандарт
а можно взять badger, где оно уже есть)
RS
Добавьте поле expiration_date и проверяйте, вот и ТТЛ. Вы все равно ходите по сети, что в редис что в основную БД. Редис не выиграет существенно времени, зато добавит потенциальную точку отказа, без которой сервис работать не будет
не expiration date а creation date
таким образом вы динамически можете определить, устарела ли сессия или нет
таким образом вы динамически можете определить, устарела ли сессия или нет
VM
Добавьте поле expiration_date и проверяйте, вот и ТТЛ. Вы все равно ходите по сети, что в редис что в основную БД. Редис не выиграет существенно времени, зато добавит потенциальную точку отказа, без которой сервис работать не будет
Обычно для авторизации запросов скорость работы важна. В случае с постгресом, например, проигрыш будет в десяток раз