knock в качестве прослойки

С devise?

нет, без всего

так как не требуется

у нас проект - это rails-api для мобильных приложений, и веб-версия (фулл-стек на рельсах). API работает на JWT-токенах через knock.

В веб-версию я пока ничего не внедрял, но если внедрять JWT - все равно нужно озаботиться о хранении токенов на клиенте, в тех же куках

В веб-версию я пока ничего не внедрял, но если внедрять JWT - все равно нужно озаботиться о хранении токенов на клиенте, в тех же куках

Это уже джаваскриптеры пусть заботятся. Но тем не менее почему без devise'a? Просто не нужно заморачиваться с кодированием паролей и т.д.

потому что он не требуется

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

Окей :) Джаваскриптеры в смысле фронтендеры. Им делать стейтлесс запросы к апи и вставлять токен в них, и обновлять его.

В веб-версию я пока ничего не внедрял, но если внедрять JWT - все равно нужно озаботиться о хранении токенов на клиенте, в тех же куках

Это я к тому написал - что просто так внедрить JWT в фул-стек рельсу и думать, что все хорошо - недостаточно

Окей :) Джаваскриптеры в смысле фронтендеры. Им делать стейтлесс запросы к апи и вставлять токен в них, и обновлять его.

а, то есть у тебя не фул-стек рельса? У тебя бек + фронт?

а, то есть у тебя не фул-стек рельса? У тебя бек + фронт?

Да

опасненько конечно

опасненько конечно

Почему?

На бекенде хватит JWT и Knock, но на клиенте нужно токены хранить в недоступном злоумышленникам месте

В мобильных приложениях это не проблема, т.к. мобильные приложения закрыты для дебаггинга простым пользователям

а в связке бек + фронт - фронт уязвим, можно палить чужие токены и использовать их

и это нехорошо

Мне еще самому предстоит с этим разобраться, изучить вопрос с CSRF, например.

Как, например, обеспечивается защита от CSRF в связке фронт+бэк

Сам по себе JWT-токен в простейшем случае - это просто зашифрованный айдишник пользователя

Зашифрованный, но не подписанный

Cookies, when used with the HttpOnly cookie flag, are not accessible through JavaScript, and are immune to XSS. You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS. This is one of the main reasons that cookies have been leveraged in the past to store tokens or session data. Modern developers are hesitant to use cookies because they traditionally required state to be stored on the server, thus breaking RESTful best practices. Cookies as a storage mechanism do not require state to be stored on the server if you are storing a JWT in the cookie. This is because the JWT encapsulates everything the server needs to serve the request.

Conclusion JWTs are an awesome authentication mechanism. They give you a structured way to declare users and what they can access. They can be encrypted and signed for to prevent tampering on the client side, but the devil is in the details and where you store them. Stormpath recommends that you store your JWT in cookies for web applications, because of the additional security they provide, and the simplicity of protecting against CSRF with modern web frameworks. HTML5 Web Storage is vulnerable to XSS, has a larger attack surface area, and can impact all application users on a successful attack.

https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage Вот эта статья. Довольно интересно.

Про CSRF согласен. Расслабляешься, когда рельсы делают всё за тебя

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

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

Там ещё комменты стоит почитать.

Это уже джаваскриптеры пусть заботятся. Но тем не менее почему без devise'a? Просто не нужно заморачиваться с кодированием паролей и т.д.

Кодирование пароля, кстати - у меня решается добавлением has_secure_password в модели User.

http://api.rubyonrails.org/classes/ActiveModel/SecurePassword/ClassMethods.html

Это добавляет в User 3 метода: password= password_confirmation= authenticate

в которых завязана вся логика по кодированию пароля (bcrypt)

Кодирование пароля, кстати - у меня решается добавлением has_secure_password в модели User.

А конфирматион мыла и восстановление пароля просто через SecureRandom base64 и последующее сравнение?

Вот над этим как раз мне предстоит подумать. Внедрять монструозный девайс просто ради восстановления пароля, либо обойтись clearance/sorcery, либо написать скромный велосипедик

Вот над этим как раз мне предстоит подумать. Внедрять монструозный девайс просто ради восстановления пароля, либо обойтись clearance/sorcery, либо написать скромный велосипедик

Как вариант просто расковырять девайс

И вытащить нужные мозги

Пока в сторону clearance склоняюсь - очень грамотный гем, на код смотреть приятно, и кастомизировать тоже, по всем канонам ООП

В исходники девайса лезть боюсь, каюсь

Пока в сторону clearance склоняюсь - очень грамотный гем, на код смотреть приятно, и кастомизировать тоже, по всем канонам ООП

thoughtbot умеют

А конфирматион мыла и восстановление пароля просто через SecureRandom base64 и последующее сравнение?

Как вариант, кстати - можно генерить тот же JWT-токен с сроком действия в условный час - вот и готова ссылка для восстановления пароля

Как вариант, кстати - можно генерить тот же JWT-токен с сроком действия в условный час - вот и готова ссылка для восстановления пароля

Да мне кажется не суть, какой токен генерировать, главное что-бы истекал. Нам же его всего один раз нужно использовать.

Хоть base64, хоть hex

Как вариант, кстати - можно генерить тот же JWT-токен с сроком действия в условный час - вот и готова ссылка для восстановления пароля

# Generate a friendly string randomly to be used as token. # By default, length is 20 characters. def self.friendly_token(length = 20) # To calculate real characters, we must perform this operation. # See SecureRandom.urlsafe_base64 rlength = (length * 3) / 4 SecureRandom.urlsafe_base64(rlength).tr('lIO0', 'sxyz') end # constant-time comparison algorithm to prevent timing attacks def self.secure_compare(a, b) return false if a.blank? || b.blank? || a.bytesize != b.bytesize l = a.unpack "C#{a.bytesize}" res = 0 b.each_byte { |byte| res |= byte ^ l.shift } res == 0 end end

Это из девайса

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

thanks, схоронил

Что такое jwt

Что такое jwt

JSON web token. Красиво и кратко: https://jwt.io/introduction/ Скучно RFC 7519: https://tools.ietf.org/html/rfc7519 TL;DR Отдаем токен в хедерах запроса к серверу, когда токен истекает его можно использовать один раз что-бы получить новый. Всё как обычно. Различные приемущества, в которых мне разбираться лень тоже присутствуют, типа дополнительная сесурити, быстрота и ещё что-то.

Amman okay

jwt жи для хранения шифрованной инфы в токене

jwt жи для хранения шифрованной инфы в токене

В том числе. Но я бы сказал просто 'хранения инфы', так как декодить jwt может любой

Как я понял.

декодить ж ток с секретным ключом

декодить ж ток с секретным ключом

Только вот секретный ключ уже есть в токене после последней точки.

А нет, все еще проще http://stackoverflow.com/questions/38552003/how-to-decode-jwt-token-in-javascript

так это же вроде если ты секрет знаешь

а так можешь на серваке шифровать -> возращать юзеру -> хранить у него -> получать от него -> расшифровывать

эт конечно всё теория, я толком в jwt въехать не могу(чем это лучше обычного uid в сессии).

верно, так и происходит

рельса шифрует payload своим каким-нибудь rake secret ключом

клиент о ключе не знает

но чем лучше то чем uid сессии? ? по сути корзину там или чет такое особо не пошаришь м/у устройствами, бравзерами. Мне вот советовали что очень ок отдавать в jwt всю инфу сразу аля роль+инфо+данные из других каких-то моделей шоб запросы к бд не делать

но как-т хз, сессию мы всё равно ж храним или я путаю теплое с мягким

верно, jwt это способ в зашифрованном виде передать сразу все нужное. Но зашифрованный - не значит подписанный, поэтому в веб среде нужно такой токен все равно хранить в куках тех же

верно, jwt это способ в зашифрованном виде передать сразу все нужное. Но зашифрованный - не значит подписанный, поэтому в веб среде нужно такой токен все равно хранить в куках тех же

а ты юзаешь jwt?

да, в API для мобильных приложений

ERROR: S client not available

секрет получается шарится м/у сервером и моб клиентом, верно?

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

секрет получается шарится м/у сервером и моб клиентом, верно?

а секрет, которым шифруются данные в токен - всегда остается только на сервере

ааа, всё, догнал - запросы потом с токеном идут(я чет думал что ты всю инфу в jwt шлёшь)

т.е. клиент токен расшифровать не может - он может его только крепить к запросам, а сервер запросы примет, расшифрует и узнает, что это за пользователь там, и стоит ли его авторизовывать

ну так же можно просто секурную строку-токен(хранимую в бд) использовать и дальше уже искать пользователя по строке этой и погнали

Можно. Если payload состоит только из id пользователя - на то оно и выйдет

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

а если к примеру тебе надо токен скинуть(аля выход из всех устройств)?

Можно так: - На сервере в БД храним у пользователя поле "крайняя дата выпуска токена" - Это же поле храним в payload токена - При запросах с токеном - сервер расшифрует его, глянет в payload[:date] и авторизует только те токены, которые были выпущены после крайней даты выпуска токена для данного пользователя - "Выход на всех устройствах" - это запрос, который обновит дату выпуска токена для текущего пользователя на сервере. Таким образом все токены, выпущенные ранее, станут недействительны

?

Ребят, можно ли релазовать двойную связь моделей? То есть, игра будет иметь юзера (создатель), а также много других юзеров (участники)?

да

Через полиморфные?

нет, зачем залезать в это?)

Я просто недавно начал, не совсем понимаю)

покажи ассоциации свои

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

class Game has_one :organizer, class_name: "User" has_many :participants, class_name: "User" end ну что-то такое я имею ввиду

Ясно, сейчас попробую. Спасибо)

@gambala А как ты реализовывал рефреш тухлого токена? Что-то типа такого на сервере?

https://puu.sh/u16DW/fffea5181b.png

В payload токена помещается дата истечения токена. Это, кстати, knock делает из коробки.

Потом сервер расшифровывает токен, смотрит в payload[:expiration_date], и если она истекла - редиректит на логин

В payload токена помещается дата истечения токена. Это, кстати, knock делает из коробки.

Ну, таки а после истечения? Заставлять юзера вводить логин/пароль?

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

Ну, таки а после истечения? Заставлять юзера вводить логин/пароль?

конечно, заставлять вводить

нормальная практика

но опять же - никто не мешает выставить дату истечения токена на пять лет

но опять же - никто не мешает выставить дату истечения токена на пять лет

А это как-нибудь отразится на безопасности?

Просто никакой сервис, коими я пользуюсь на телефоне, например (ну или в вебе, на телефоне лучше пример - потому что там всегда апи и всегда токен), не просит вводить пароль больше одного раза. Если только ты не сбросил данные

Значит либо там перманент токен, либо он рефрешится