LINUX.ORG.RU

Прикрутить логин

 


0

2

Привет. Нужно прикрутить логин. Вопрос - как это сделать правильно? Мне вот что в голову идет - сохранять на странице некий ID, который вписывается сервером в код страницы после логина клиента и действует некоторое время (минут 5, например). Вопрос, я все правильно делаю, не через зад? Сама концепция не кривая? Пишу сервер на kore.

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

Дёшево и сердито – cookies (stateful), более по фен-шую jwt (stateless).

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)

Любой скрипт сможет получить доступ к твоему id, если это устраивает, то для учебного варианта или самописного «велосипеда» ок. Если нет, то можно сохранять в HttpOnly Cookie или еще что-нибудь придумать. Это конечно без учета защит от всяких атак типа csrf.

orm-i-auga ★★★★★ ()
Последнее исправление: orm-i-auga (всего исправлений: 1)
Ответ на: комментарий от vvn_black

Кстати, там же с куками все тяжко - надо уведомлять пользователя о сохранении у него, а мне как раз нужно впендюрить сайт за границами РФ, да еще и вход через соц сети, а там сторонние куки. Бред какой-то …

pavlick ★★ ()
Последнее исправление: pavlick (всего исправлений: 1)
Ответ на: комментарий от pavlick

надо уведомлять пользователя о сохранении у него

Я, конечно, не уверен, но по-моему это касается трекеров и сторонних скриптов.

И, разве, плашку тяжело прилепить?

vvn_black ★★★★★ ()
Ответ на: комментарий от beastie

Дёшево и сердито – cookies (stateful), более по фен-шую jwt (stateless)

Эти вещи не взаимоисключающие.

более по фен-шую jwt (stateless)

Говно эти ваши stateless jwt для сессий. Алсо, FYI.

theNamelessOne ★★★★★ ()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ты видимо не понял вообще вопроса. Говорилось о получении инфы о клиентском железе из JS запущенного на клиентской стороне. Во-первых уже не надо, а во-вторых знаю одну контору, которая компилирует код, который запускается лишь на конкретной машине, всю необходимую инфу они получает через браузер, значит можно.

pavlick ★★ ()
Ответ на: комментарий от theNamelessOne

а ты вообще знаешь что это? такое ощущение, что ты сам не разбираешься в теме и всех этих приколов с <img src="http://site.com/account/delete" /> не видел. просто нубством в одном конкретном вопросе прямо таки и прет

tz4678 ★★ ()
Ответ на: комментарий от tz4678

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

Да-да, все вокруг нубы и не знаю элементарных вещей, один ты умный, в белом пальто стоишь красивый!

Фраза «JWT решает проблему CSRF» глупая тем, что JWT по сути никак не связан с проблемой защиты от CSRF, эта проблема ортогональная. Можно не использовать куки и хранить информацию о юзере (которая не обязана быть закодирована с использованием JWT) в каком-нибудь localStorage (только теперь она становится доступна вообще для всех скриптов). Либо можно просто прикрутить CSRF-защиту для запросов, благо в большинстве экосистем это делается минут за 30.

theNamelessOne ★★★★★ ()
Ответ на: комментарий от theNamelessOne

Либо можно просто прикрутить CSRF-защиту для запросов

Такая защита - это input type=hidden с хешем в value. Прямо таки для всех… Ага. А куки подключаемые скрипты совсем читать не умеют. Ок. Один ты умный, в белом пальто стоишь красивый!

tz4678 ★★ ()
Ответ на: комментарий от tz4678

Такая защита - это input type=hidden с хешем в value. Прямо таки для всех…

И что? (Не обязательно hidden-инпут, можно и при ручных AJAX-запросах передавать жавоскриптом, можно даже в заголовках).

А куки подключаемые скрипты совсем читать не умеют

Ох, т.е. про HTTP-only cookie ты тоже не слышал?

theNamelessOne ★★★★★ ()
Последнее исправление: theNamelessOne (всего исправлений: 1)
Ответ на: комментарий от theNamelessOne

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

tz4678 ★★ ()