MAGI
про авторизацию на слое приложения
MAGI
а если там например на объекте только определенные люди могут выполнять действие?
Anton
про авторизацию на слое приложения
Заказ не должен задумываться о том кто может его отменить
MAGI
ну либо пример с заказом и отменой только определенными людьми при определенных обстоятельствах
Anton
Контекст должен быть ограничен
MAGI
окей, метод отмены да
MAGI
но сама логика вот эта что может отменяться только в таких то и таких то статусах
MAGI
это разве не БЛ?
Anton
This constitutes a new Bounded Context - the Identity and Access Context - and will be used by other Bounded Contexts through standard DDD integration techniques. To the consuming contexts the Identity and Access Context is a Generic Subdomain. The product will be named IdOvation. So according to Vernon probably the best solution to move the access control to a generic subdomain.
Anton
вот по вернону это вообще поддомен
Anton
тогда это не слой приложения
Anton
вообще я пока не встречал в жизни DDD кроме как в книгах и гитхабе =)
Anton
получается что это все таки БЛ, но в отдельном контексте
MAGI
ну так все четко, согласен
MAGI
как полиси и метод
MAGI
если на лару переводить)
Anton
DDD и доменные модели - сложно, в 95% случаях только проблемы создает как я понимаю
Anton
нужно быть проще =)
Stas
Всем привет
Stas
Не могу понять сделал jwt авторизацию , авторизируюсь
Stas
{"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vZGVudGEubG9jL2FwaS9sb2dpbi91c2VyIiwiaWF0IjoxNTI4Mzg4NTI4LCJleHAiOjE1MjgzOTIxMjgsIm5iZiI6MTUyODM4ODUyOCwianRpIjoiNmlaTWZXOWtxTm1pUlFxbCIsInN1YiI6MSwicHJ2IjoiODdlMGFmMWVmOWZkMTU4MTJmZGVjOTcxNTNhMTRlMGIwNDc1NDZhYSJ9.n4SB4knTlgOq2dTWD7wY29cjy5iAxK7hEe0sRis-jAs","token_type":"bearer","expires_in":3600}
Stas
Но когда перехожу на
Stas
Route::group(['middleware' => 'api',], function ($router) { Route::post('me', 'Auth\LoginController@me'); });
Stas
public function me(Request $request) { return response()->json($this->guard()->user()); }
Stas
Возвращает пустой {}
Stas
Мне нужен remember_token в таблице users?(
MAGI
а ты в миддлваре делаешь логин юзера ?
MAGI
грубо говоря, откуда у тебя гвард будет знать какой сейчас юзер
Stas
Аааа спасибо
Stas
Наверное нет
Евгений
я поясните мне за jwt. Мы для клиента генерируем токен и время жизни. И уже сам клиент должен озаботиться тем как его потом обновлять?
Евгений
например мобильное приложение если делать
Andy
например мобильное приложение если делать
в мобильном приложении после авторизации нужно класть токен в store, если приложение без приблуд, то токен должен быть живучим
Евгений
то есть не задавать время действия токена?
Andy
сделал vue.js laravel jwt и обломался с приложением. пришлось заюзать passport
Евгений
мне угодно понять как принято
Andy
то есть не задавать время действия токена?
фронт и приложение две разные вещи) приложение по дефолту приватное чисто юзерское) а на сайт можно с кафе зайти. сделай 2 авторизации
Евгений
эм
Евгений
"приложение по дефолту приватное чисто юзерское)" не понял фразу
silks
только присоединился, и вижу сообщения про секс с токенами на vuejs&laravel
Andy
ну телефон у тебя всегда в кармашке)
Евгений
silks
это я так рефлексирую. у меня то он есть. целый день сегодня курю тему.
Andy
забудьте про обычное jwt, если вдруг захотите в личном кабинете возможность юзеру убить сессию на каком-либо девайсе. passport/oauth это умеет, на всем остальном можно нагородить велосипедов
silks
вприципе все. пока что изучаю просто изучаю.
Andy
можешь развить мысль?)
я имел в виду, что в приложении токен как бы не должен сгорать. тк у тебя на логин скрине пароль/тач/глаза + в приложении может быть доп.пароль. а на сайте по идее желательно токен делать сгораемым
Andy
бля сори просто мысли вслух, тк сделал дополнительной работки по этой теме и уже обжегся в app’e
Евгений
это какая то best practice или из своего опыта? я просто api еще не разрабатывал и сейчас как раз возмрожно придётся, вот и хочу разобраться. Хотя лучше пойду в интернеты за ответами
Andy
это какая то best practice или из своего опыта? я просто api еще не разрабатывал и сейчас как раз возмрожно придётся, вот и хочу разобраться. Хотя лучше пойду в интернеты за ответами
если планируется приложение, то best practice давать возможность юзеру разлогиниться везде, за исключением текущей сессии или на определенном девайсе. стандартный jwt с vue на фронте ок, но не с приложухой. просто экономлю тебе часы времени)
Евгений
мне просто представлялось что passport это чтото типа чтобы делать api как вконтакте, когда юзер себе приложуху создает для взаимодействия с апи, а я могу его потом ограничивать или отключать. Ладно, в чате всё равно не то, в интернетах буду искать инфу
Roman
Как Андроид-разраб скажу. Лучше для приложений токены делать живучими. Уж 100% не на 15-20 минут)) Или ясный механизм их рефреша. Но тогда все равно токен должен жить далеко не один день.
Andy
трабл в том, что приложение может работать с обычной сессионной кукой. но для фронта это не ок) можешь даже не юзать passport и oauth. просто доп.поле в бд у юзера, в котором токен, который в свою очередь в store приложения. далее сравнение credentials и тд
Евгений
ну то есть фронт сайта - это все кому не лень, приложение - тоже
Евгений
понял
Andy
так проще ведь оставить на фронте jwt с рефрешем, а для приложения просто добавить чутка кода с отдельной авторизацией
Andy
ну так Евгений вроде как oauth не хочет
Andy
у меня oauth2 и фронт и app)
MAGI
https://dev.to/neilmadden/7-best-practices-for-json-web-tokens
MAGI
6 пункт
MAGI
мне лично понравилась идея с блэклистом
MAGI
если, допустим, хранишь дату выдачи токена в нем и юзер айди то пишешь в блэклист айди юзера и дату, с которой токены считаются валидными(момент ревока токена)
MAGI
хотя там вроде это дефолтные поля))
Igor
а вот не знаю чото
как я понял из лога - одним запросом
Andy
если, допустим, хранишь дату выдачи токена в нем и юзер айди то пишешь в блэклист айди юзера и дату, с которой токены считаются валидными(момент ревока токена)
выход из приложения и показ story с логином заключается просто в удалении из store токена. все эти действия производятся без участия api. после логина дается новый токен и приложение оживает. какой блэклист, блин?
Andy
я есть грут
silks
я есть грут
не ешь его, он деревянный))
Roman
Раз уже тут зашла мобильная тема. Я новичок в back-end. Только начал изучать. И что меня удивило: это всякие шаблонизаторы вроде blade. Я думал, что уже давно почти все сайты сложнее блога используют API. С json- запросами и -ответами, токенами и т.д. По идее же бек от фронта должен быть отделён, не так ли? Чтобы его могли те же фронт-ендщики делать, не таща с собой весь проект? Да и мобильное приложение по-другому не сделаешь. А тут всё через blade фигачится... Или я чего-то не понимаю? 🤔 Прошу камнями не кидаться.
Roman
Да просто интересно и странно) Во всех уроках, что вижу, через него всё делается. Так принято делать или как
SarcasmIO
просто учат делать сначала абыкак
Александр
Каждому проекту свой стек, не понимаю, откуда взялась вот это вот понятие, что не пилить спа - дурной тон?
Anonymous
...
Igor
$countriesIds = $_POST['countries']; $genresIds = $_POST['genres']; $films = Film:: whereHas('country', function($query) use ($countriesIds) { $query->whereIn('country_id', $countriesIds); }) ->whereHas('genres', function($query) use ($genresIds) { $query->whereIn('id', $genresIds); }) ->get(); Допустим страны или жанры не выбраны. Тогда появится ошибка Как сделать так чтобы если не выбраны страны / жанры выводилось всё что есть? Запрос собранный конструктором выглядит так: select * from `films where exists (select * from countries where films.country_id = countries.id and country_id in (?)) and exists (select * from genres inner join film_genre on genres.id = film_genre.genre_id where films.id = film_genre.film_id and id in (?)) `