мне кажется сама идея "писать бэк для мобилки" должна быть как самая крайняя мера когда по другому никак

Хм

Во всех случаях?

Во всех случаях?

что значит во всех случаях?)) я ж говорю - во всех случаях когда можешь не писать - не пиши) то что будет существенный процент случаев когда "не писать не выйдет" - это факт, но даже в рамках одного проекта у тебя 2/3 может крутиться в firebase каком а 1/3 на php

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

и начнется карусель "надо было делать своё" )

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

или сервис просто раком загнется через год два

и начнется карусель "надо было делать своё" )

вопрос инвестиций и рисков

у тебя есть два пути - инвестировать время (и деньги) в разработку своего или взять готовое и запустить продукт

ну и опять же - у всех популярных решений есть клон на github

просто не такой крутой и не такой удобный

пример из жизни: 1. надо запустить продукт в течении 2-х месяцев. Там для одной из фич нужны были чатики. Взяли готовый сервис 2. спустя 1 месяц пришли очередные изменения требований и оказалось что "нет таких готовых чатиков которые нам подходят".... пришлось лепить кастыли на webhook-ах (~1 человекомесяц) что бы было клево. Профит от готового сервиса все еще есть в виде готового UI SDK. 3. спустя 6 месяцев когда продукт уже в продакшене решили переделать UI. UI SDK для готового сервиса уже не подходит, перепиливаем и делаем кастомный UI. 4. спустя еще 3 месяца новая пачка изменений требований которые вот вообще не выгодно делать на готовом решении (банально по баблу не выгодно уже и по сложности поддержки). Выделяем команду из 2-х человек на месяц что бы заебенили свои чатики чисто под нас. 5. выкидываем готовое решение

или сервис просто раком загнется через год два

шансы что твой проект загнется после релиза намного выше)

а потому лучше экономить там где риски выше

кароч надо бухнуть и все пройдет

наверное это просто накопившийся стресс

или вот еще что бесит - "у нас новый проект... мы будем юзать php, symfony, mysql, nginx.... что там запилить надо?"

а видел тз "хотим как тут" ?

я вот видел, как раз сейчас вот его и делаю

а видел тз "хотим как тут" ?

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

3 блять слова "сделайте как тут" )

3 блять слова "сделайте как тут" )

тебя научить как требования собирать?)

это был уже проданый проект

там этап сбора этих требований прошел еще до моего найма )

и все что удалось собрать "сделайте как тут?" мне кажется аналитика или кто там у тебя сбором требований занимается следует уволить

не ну я конечно уточнял детали как без этого

3 блять слова "сделайте как тут" )

чисто для статистики - логин это одна из первых фич за которую вы взялись?)

не

наоборот откладывал как мог

норм

@fes0r а что думаешь насчёт реализации авторизации и регистрации с использованием архитектуры REST API?

ахах

Сорян если тупо спросил)

Я просто почитал о чем вы беседовали по этому поводу и у меня туториал на Udemy куплен на эту темы, ещё не смотрел его, но мож че толковое

Почитай jwt.io

Это аутентификация

спрашивать про рестапи в пятницу вечером самое то )

Я просто почитал о чем вы беседовали по этому поводу и у меня туториал на Udemy куплен на эту темы, ещё не смотрел его, но мож че толковое

А что на счёт нее можно думать?

Почитай jwt.io

Спасибо за инфу! Очень круто, посмотрим как усвоится материал!

@fes0r а что думаешь насчёт реализации авторизации и регистрации с использованием архитектуры REST API?

"с использованием архитектуры REST".... вот на этом моменте я пожалуй и не буду продолжать

Почитай jwt.io

не надо ему JWT

?

bin2hex(openssl_random_pseudo_bytes(32))

и впуть дорогу

можно сверху фильтр блума жахнуть шутки ради

не надо ему JWT

Чего это ?

?

по JWT погугли почему не стоит юзать JWT для сессий

JWT это как раз таки для АВТОРИЗАЦИИ а не аутентификации)

когда ты третьей стороне разрешение даешь - тут JWT удобно

как и всякие другие HMAC

Та я помню тред про jwt

Та я помню тред про jwt

не повторяйте моих ошибок

не юзайте JWT если не понимаете в чем смакота HMAC

Та пока не споткнёшься - знать не будешь))

я стольким людям JWT советовал в свое время.... гореть мне...

Я помню что в детстве говорили не пивать ничего в розетки

Но я понял это только когда замкнул круг и вылетели пробки

Сейчас понимаю что мне там могла быть крышка

"с использованием архитектуры REST".... вот на этом моменте я пожалуй и не буду продолжать

Я чёт не догнал походу.. но я прочёл что rest это архитектурный стиль такой

Вбросить чтоли. Пятница же

Я чёт не догнал походу.. но я прочёл что rest это архитектурный стиль такой

"архитектурный стиль" и "архитектура" - найти 10 отличий

Вбросить чтоли. Пятница же

я могу себя порекламить)

https://www.youtube.com/watch?v=2nELo4fJMNQ

ERROR: S client not available

я там конечно херню несу но...

не юзайте JWT если не понимаете в чем смакота HMAC

есть что почитать?

ну или краткую выжимку от первого лица, а дальше я уже сам в гугл пойду

я там конечно херню несу но...

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

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

я так и не выложил(

пиздюк я, да

потому что нечего писать, либо нельзя унифицировать потому что все зависит от проекта, либо все есть в симфони из коробки. А проблема в основном в том что с symfony/security мало кто разбирался, как никак это самый сложный после форм компонент

а чем сложны формы ?

Hi all

а чем сложны формы ?

там много всего, большинство тыкало может быть 10-15% из того что там есть.... ну я не знаю как по другому объяснить то как формы юзают в основном...

Кто-то пробовал отделять Credential от профиля юера, я вот увидел интересную идею от @fes0r ? И вот что у меня получилось https://gist.github.com/misterx/6a5ec71fe53abb744d27dbbbcb3cdccf Но вопрос стоит в энкодере пароля. Куда его запихнуть?

Кто-то пробовал отделять Credential от профиля юера, я вот увидел интересную идею от @fes0r ? И вот что у меня получилось https://gist.github.com/misterx/6a5ec71fe53abb744d27dbbbcb3cdccf Но вопрос стоит в энкодере пароля. Куда его запихнуть?

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

А зачем тебе addCredential у юзера?

А зачем тебе addCredential у юзера?

Потому что у меня есть 2 сущности, есть Admin и есть User ... они по m2m на Credentials

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

хм ... а для чего это? )

хм ... а для чего это? )

ну тип самый норм вариант если не заморачивашьеся - password_hash($password, PASSWORD_DEFAULT)

в php 7.2 дефолты это bcrypt, в 7.3 дефолты это ARGO2 (вроде так называется)

ну тип самый норм вариант если не заморачивашьеся - password_hash($password, PASSWORD_DEFAULT)

А если там токен, а не пароль, который не надо хешировать ?

А если там токен, а не пароль, который не надо хешировать ?

я бы менял имплементацию

оставляя одну и ту же модель данных

На сколько я понимаю концепцию, и к чему я иду, то все креды лежат в этой табличке

да, но соль не в том что бы все креды лежали в одной табличке, соль в том что бы они лежали отдельно от всей остальной системы

да, но соль не в том что бы все креды лежали в одной табличке, соль в том что бы они лежали отдельно от всей остальной системы

Ну просто если делать на каждые креды отдельную таблицу, то это будет ппц...кмк. Например есть фб, гугл, апи, форма логина, и есть 2 типа юзеров. Получается что надо 4 * 2 = 8 таблиц? И если добавить еще один тип то еще + 4 таблицы. Ес?

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

Ну просто если делать на каждые креды отдельную таблицу, то это будет ппц...кмк. Например есть фб, гугл, апи, форма логина, и есть 2 типа юзеров. Получается что надо 4 * 2 = 8 таблиц? И если добавить еще один тип то еще + 4 таблицы. Ес?

я не к тому что бы делать по таблице на каждый тип, я к тому что нет никаких ограничений)

я тебе могу накинуть еще парочку юзкейсов относительно пароля

я не к тому что бы делать по таблице на каждый тип, я к тому что нет никаких ограничений)

Вот тут не понял )

1. пароль не должен входить в top1000 самых распространенных паролей 2. когда пользователь меняет пароль - нельзя что бы он юзал пароль который уже юзал (историю например на 10 последних паролей)

вот тебе два юзкейса на подумать

оба юзкейса опциональны

1. пароль не должен входить в top1000 самых распространенных паролей 2. когда пользователь меняет пароль - нельзя что бы он юзал пароль который уже юзал (историю например на 10 последних паролей)

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