Рекомендую осваивать linux на virtualbox. И вообще разрабатывать на виртуальных машинах, которые схожи с целевым устройством — хорошо

то есть не разрабатывать, а тестировать

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

товарищи Ярошенко и Лопатин в курсе об этом чате? Или они слишком крутые для него?

Лопатину не до чатов, а Ярошенко думаю тоже слишком занят

Ну а так да) подтянуть их сюда про мои любимые файберы в 1001 раз поговорить)

Лопатин так и сказал?

Я с ним когда списывался он постоянно на нехватку времени жаловался

кто-нибудь с авторизацией и rest работал?

чёт вопросов масса

можно начать с вопроса о передаче пароля из браузера и вообще авторизации

если по ssl, то не нужно ничего замешивать на клиенте?

кстати, там либа для oAuth одна есть на гитхабе

если вдруг нужно будет

смотрел, чёт пока не понял подходит оно или нет

насколько я знаю хранить пароли в базе напрямую не очень хорошо... подмешивать соль при передаче пароля лучше на клиенте?

вообще простой способ для этого есть или это js реализуется?

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

и вот собственно второй по поводу rest авторизовываться то получается нужно в rest? тоесть там проверять логин-пароль

код не идеальный, но написан очень аккуратно

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

сама по себе простая авторизация у меня уже есть

просто пароль передаётся голый

так он же по https передается. если так то проблем быть не должно

а в базе значит тоже голый хранить? не дело это... надо шифровать как-нибудь

ну хэширование тогда логин+пароль

и я не совсем понимаю как с rest'ом потом работать правильно

вот я сверил, хорошо, есть такой пользователь

токен могу сгенерировать

его потом в сессию класть?

а в базе значит тоже голый хранить? не дело это... надо шифровать как-нибудь

Так соль и перец добавляй перед хранением. Что тебя останавливает?

чтобы web интерфейс мог с rest работать по js

Так соль и перец добавляй перед хранением. Что тебя останавливает?

если по ssl это можно и на сервере делать или всё-таки на клиенте лучше сразу засолить?

его потом в сессию класть?

В куки положи. Или пусть клиент каждый раз добавляет свой токен. Одно и тоже получается.

если по ssl это можно и на сервере делать или всё-таки на клиенте лучше сразу засолить?

А смысл солить на клиенте? Тоже самое, что и голый пароль.

А смысл солить на клиенте? Тоже самое, что и голый пароль.

хотя да...

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

бред, согласен

вот сейчас подумал

а зачем солить то?

читал про это читал...

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

JWT посмотри еще — кажется так называется

хотя... нет...

https://github.com/olehlong/jwtd

авторизация будет солить и если отправить засоленый, то он пересолится и будет другим

оке, кажется я понял зачем)))

что зачем? зачем солить?

что зачем? зачем солить?

да

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

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

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

что это даёт по сравнению с простой солью в конфиге или в коде?

Тогда это перец, а не соль.

ок, ладно

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

Так, а как красиво проверить не оканчивается ли путь на слеш чтобы если оканчивается убрать его

Так, а как красиво проверить не оканчивается ли путь на слеш чтобы если оканчивается убрать его

в std.path вроде было что-то

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

Если базу украдут, то радужные таблицы мало чем помогут.

да я смотрю туда. только что-то не вижу фишку отсекающую последний слешь если он есть

Если базу украдут, то радужные таблицы мало чем помогут.

понял

спасибо большое за разъяснение

да я смотрю туда. только что-то не вижу фишку отсекающую последний слешь если он есть

https://dlang.org/phobos/std_string.html#.chomp

Пожалуйста.

о точняк! пасибо!

@sigod ещё вопрос по безопасности получается web-сервис должен отдавать страницу, где в каком-то скрытом теге лежит token доступа, так?

а его уже читает js для обращения к rest

Обычно просто в куках передаётся токен сессии.

куки читаются из js?

ERROR: S client not available

Так они посылаются на сервер с каждым запросом. Для JS не надо ничего делать.

так rest же не поддерживает сессии и куки

архитектура такая: есть rest со всем функционалом и есть web морда, которая этот функционал юзает через js

по сему как-то нужно в js передать значение авторизованного токена

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

да да, примерно

будет страницы 3-4, но на 2х будет активно эксплуатироваться rest

Страница загрузилась. Клиент авторизовался и получил токен. Всё, JS во все запросы добавляет данный токен и всё работает.

так как безопасней передать токен в js?

ааа... кажется понял

авторизацию тоже через js сделать видимо имеет смысл

хотя нет...

страниц всё-равно несколько

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

Тем более, что как ты скажешь им не посылаться? Не уверен, что такое можно через JS.

тоесть просто выставляю токен в куки и всё?

потом его юзаю для работы с rest, так?

Просто используй сессию.

Чистый REST хорош для сторонних сервисов. Например, того же Facebook. Когда твоё приложение или сервер к нему обращается.

Чистый REST хорош для сторонних сервисов. Например, того же Facebook. Когда твоё приложение или сервер к нему обращается.

помимо web, возможно, будет desktop и mobile клиенты, наш же rest будет обращаться к yandex и google

вместо web мы сейчас могли просто desktop gtk запилить, но выбрали web

Просто используй сессию.

поэтому нам нужно токен в js запросах

Солить можно алгоритмом bcrypt

Точнее не солить, просто хеш взять от пароля и положить как есть в базу

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

Когда клиент/десктоп логинится на сайт, он посылает чистый пароль по SSL соединению, это безопасно. Сервер хеширует его, проверяет. И выдает клиенту временный сгенерированный токен сессии.

Нахуй куки. Логинишься js, токен кладешь в localStorage и при ajax запросе добавляешь HTTP заголовок Authorization

Нахуй куки. Логинишься js, токен кладешь в localStorage и при ajax запросе добавляешь HTTP заголовок Authorization

что с куками не так? уже сделал прост через них

вообще не в курсе что такое localStorage

Если у вас там desktop/mobile клиенты планируются, то куки плохой вариант. Делай как Зло говорит.

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

Нынче не проблема получить доступ к хорошей rainbow table. Простое хеширование пароля уже не имеет смысла.

bcrypt не простое хешироаание