окей, метод отмены да

а если там например на объекте только определенные люди могут выполнять действие?

вот это как раз интересно. тот самый момент, когда авторизация коснется домена.

но сама логика вот эта что может отменяться только в таких то и таких то статусах

это разве не БЛ?

особенно если это Write модель только...

окей, метод отмены да

даже метод отмены. отменить могут админы и еще заказавший этот заказ ?

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.

вот по вернону это вообще поддомен

тогда это не слой приложения

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

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

вообще я пока не встречал в жизни DDD кроме как в книгах и гитхабе =)

получается что это все таки БЛ, но в отдельном контексте

ну так все четко, согласен

как полиси и метод

если на лару переводить)

DDD и доменные модели - сложно, в 95% случаях только проблемы создает как я понимаю

нужно быть проще =)

вообще я пока не встречал в жизни DDD кроме как в книгах и гитхабе =)

Как и честный рестфул

Всем привет

Не могу понять сделал jwt авторизацию , авторизируюсь

{"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vZGVudGEubG9jL2FwaS9sb2dpbi91c2VyIiwiaWF0IjoxNTI4Mzg4NTI4LCJleHAiOjE1MjgzOTIxMjgsIm5iZiI6MTUyODM4ODUyOCwianRpIjoiNmlaTWZXOWtxTm1pUlFxbCIsInN1YiI6MSwicHJ2IjoiODdlMGFmMWVmOWZkMTU4MTJmZGVjOTcxNTNhMTRlMGIwNDc1NDZhYSJ9.n4SB4knTlgOq2dTWD7wY29cjy5iAxK7hEe0sRis-jAs","token_type":"bearer","expires_in":3600}

Но когда перехожу на

Route::group(['middleware' => 'api',], function ($router) { Route::post('me', 'Auth\LoginController@me'); });

public function me(Request $request) { return response()->json($this->guard()->user()); }

Возвращает пустой {}

Мне нужен remember_token в таблице users?(

а ты в миддлваре делаешь логин юзера ?

грубо говоря, откуда у тебя гвард будет знать какой сейчас юзер

Аааа спасибо

Наверное нет

я поясните мне за jwt. Мы для клиента генерируем токен и время жизни. И уже сам клиент должен озаботиться тем как его потом обновлять?

например мобильное приложение если делать

например мобильное приложение если делать

в мобильном приложении после авторизации нужно класть токен в store, если приложение без приблуд, то токен должен быть живучим

то есть не задавать время действия токена?

сделал vue.js laravel jwt и обломался с приложением. пришлось заюзать passport

мне угодно понять как принято

то есть не задавать время действия токена?

фронт и приложение две разные вещи) приложение по дефолту приватное чисто юзерское) а на сайт можно с кафе зайти. сделай 2 авторизации

эм

"приложение по дефолту приватное чисто юзерское)" не понял фразу

только присоединился, и вижу сообщения про секс с токенами на vuejs&laravel

ну телефон у тебя всегда в кармашке)

ну телефон у тебя всегда в кармашке)

можешь развить мысль?)

это я так рефлексирую. у меня то он есть. целый день сегодня курю тему.

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

вприципе все. пока что изучаю просто изучаю.

можешь развить мысль?)

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

бля сори просто мысли вслух, тк сделал дополнительной работки по этой теме и уже обжегся в app’e

это какая то best practice или из своего опыта? я просто api еще не разрабатывал и сейчас как раз возмрожно придётся, вот и хочу разобраться. Хотя лучше пойду в интернеты за ответами

это какая то best practice или из своего опыта? я просто api еще не разрабатывал и сейчас как раз возмрожно придётся, вот и хочу разобраться. Хотя лучше пойду в интернеты за ответами

если планируется приложение, то best practice давать возможность юзеру разлогиниться везде, за исключением текущей сессии или на определенном девайсе. стандартный jwt с vue на фронте ок, но не с приложухой. просто экономлю тебе часы времени)

мне просто представлялось что passport это чтото типа чтобы делать api как вконтакте, когда юзер себе приложуху создает для взаимодействия с апи, а я могу его потом ограничивать или отключать. Ладно, в чате всё равно не то, в интернетах буду искать инфу

Как Андроид-разраб скажу. Лучше для приложений токены делать живучими. Уж 100% не на 15-20 минут)) Или ясный механизм их рефреша. Но тогда все равно токен должен жить далеко не один день.

трабл в том, что приложение может работать с обычной сессионной кукой. но для фронта это не ок) можешь даже не юзать passport и oauth. просто доп.поле в бд у юзера, в котором токен, который в свою очередь в store приложения. далее сравнение credentials и тд

Как Андроид-разраб скажу. Лучше для приложений токены делать живучими. Уж 100% не на 15-20 минут)) Или ясный механизм их рефреша. Но тогда все равно токен должен жить далеко не один день.

не знаю про андройд, я пока на ios только. но механизм по идее везде одинаков

ну то есть фронт сайта - это все кому не лень, приложение - тоже

понял

так проще ведь оставить на фронте jwt с рефрешем, а для приложения просто добавить чутка кода с отдельной авторизацией

ну так Евгений вроде как oauth не хочет

у меня oauth2 и фронт и app)

https://dev.to/neilmadden/7-best-practices-for-json-web-tokens

6 пункт

мне лично понравилась идея с блэклистом

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

хотя там вроде это дефолтные поля))

а вот не знаю чото

как я понял из лога - одним запросом

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

выход из приложения и показ story с логином заключается просто в удалении из store токена. все эти действия производятся без участия api. после логина дается новый токен и приложение оживает. какой блэклист, блин?

выход из приложения и показ story с логином заключается просто в удалении из store токена. все эти действия производятся без участия api. после логина дается новый токен и приложение оживает. какой блэклист, блин?

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

я есть грут

я есть грут

не ешь его, он деревянный))

Раз уже тут зашла мобильная тема. Я новичок в back-end. Только начал изучать. И что меня удивило: это всякие шаблонизаторы вроде blade. Я думал, что уже давно почти все сайты сложнее блога используют API. С json- запросами и -ответами, токенами и т.д. По идее же бек от фронта должен быть отделён, не так ли? Чтобы его могли те же фронт-ендщики делать, не таща с собой весь проект? Да и мобильное приложение по-другому не сделаешь. А тут всё через blade фигачится... Или я чего-то не понимаю? ? Прошу камнями не кидаться.

Да просто интересно и странно) Во всех уроках, что вижу, через него всё делается. Так принято делать или как

Да просто интересно и странно) Во всех уроках, что вижу, через него всё делается. Так принято делать или как

нет

просто учат делать сначала абыкак

Раз уже тут зашла мобильная тема. Я новичок в back-end. Только начал изучать. И что меня удивило: это всякие шаблонизаторы вроде blade. Я думал, что уже давно почти все сайты сложнее блога используют API. С json- запросами и -ответами, токенами и т.д. По идее же бек от фронта должен быть отделён, не так ли? Чтобы его могли те же фронт-ендщики делать, не таща с собой весь проект? Да и мобильное приложение по-другому не сделаешь. А тут всё через blade фигачится... Или я чего-то не понимаю? ? Прошу камнями не кидаться.

А потом эти же фронтендщики через костыли поднимают свой фронт на ноде для серверного ренднринга

Каждому проекту свой стек, не понимаю, откуда взялась вот это вот понятие, что не пилить спа - дурной тон?

Раз уже тут зашла мобильная тема. Я новичок в back-end. Только начал изучать. И что меня удивило: это всякие шаблонизаторы вроде blade. Я думал, что уже давно почти все сайты сложнее блога используют API. С json- запросами и -ответами, токенами и т.д. По идее же бек от фронта должен быть отделён, не так ли? Чтобы его могли те же фронт-ендщики делать, не таща с собой весь проект? Да и мобильное приложение по-другому не сделаешь. А тут всё через blade фигачится... Или я чего-то не понимаю? ? Прошу камнями не кидаться.

степень развития человека: blade + laravel api -> vue.js + laravel api -> vue ssr node express + laravel api ->>> mozno ostanovitsja na vremja

...

$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 (?)) `

Каждому проекту свой стек, не понимаю, откуда взялась вот это вот понятие, что не пилить спа - дурной тон?

spa быстрее делать ровно в 2 раза, чем гибридное vue js + blade + api

$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 (?)) `

Сначала ответь на вопрос - как вытащить и обработать пришедшие в запросе параметры? Вижу сразу, что доку не читал и читать не собираешься. Ты думаешь, тебе кто-то поможет?

Сначала ответь на вопрос - как вытащить и обработать пришедшие в запросе параметры? Вижу сразу, что доку не читал и читать не собираешься. Ты думаешь, тебе кто-то поможет?

Доку читал и читать собираюсь) Правда с её пониманием у меня печальненько.