Я делаю несложное SPA на Vue + Laravel (Rest API). Есть таблица пользователей и аутентификация по логину и паролю.
По умолчанию в Laravel для web используется session guard, а для api - token.
Я не могу понять, почему задумано разделение в рамках одного проекта?
Я же могу использовать session driver для ajax-запросов к API? Просто мне не очевидно в чём преимущества токена в моем случае. Да и вообще не понятно зачем разделять на api и web роуты, конфиги?
Да, но аутентификация нужна. Получается, что токен, что id сессии мы будем хранить на клиенте в куках (или в localStorage). И разница в том, что по токену не будет загружаться запись юзера из сессии, а сразу из базы. Так?
И разница в том, что по токену не будет загружаться запись юзера из сессии (stateless же), а сразу из базы. Так?
щито?
Получается, что токен, что id сессии мы будем хранить на клиенте в куках (или в localStorage)
в целом да, только не совсем.
1. юзер заходит через обычную форму входа и получает сессию
2. пока сессия есть на страницу выдается токен в виде метатега
3. работает с апи с помощью этого токена
итого апи токен не хранится на клиенте, но работа идет с апи все равно. гибридный вариант получается.
ну а если чисто через апи работать, то да хранить токен в браузере иначе придется при перезагрузке страницы логиниться каждый раз.
Александр Аксентьев, Почитал ваш ответ и посмотрел на исходники гвардов. То есть, как я понял, алгоритм аутентификации обоих гвардов такой: сессия
1. получаем id сессии с клиента,
2. получаем id пользователя из сессии и загружаем его по этому id из базы. Если сессия умерла, то загружаем по remember_token (если есть). токен
1. просто сверяем переданный токен с полем api_token таблицы users и загружаем юзера. Не совпало? Логинься заново, получай новый, который запишется в эту таблицу.
--------------------------------------------------
То есть по факту, если хранить токен на клиенте, получаем одно и тоже поведение, просто без лишней прослойки в виде самой сессии? Разница чисто идеологическая.
Меня смутило, что по умолчанию для обычных запросов в ларе используется один способ, а для rest - второй. Ведь в паре они точно работать не будут нормально! Авторизировавшись через веб, rest запрос попросит ещё раз, но через токен. В принципе, раз у меня SPA, то я могу отказаться от web-гварда и остановиться только на токенах.
то есть, как я понял, алгоритм аутентификации обоих гвардов такой:
да
Меня смутило, что по умолчанию для обычных запросов в ларе используется один способ, а для rest - второй.
Потому как апи первоначально задумывалось как протокол для работы с другими серверами т.е. к апи обращается не браузер, а другой сервер у которого нет состояния никакого и оно ему не нужно. https://www.quora.com/Why-is-REST-web-service-alwa...
l4m3r, а в целом никто не запрещает закинуть мидлварь сессии на группу api роутов или просто вынести в глобальный список мидлварей и сессии будут работать на апи и на вебе и не надо запариваться с апитокенами.
но это такое себе конечно.
Александр Аксентьев, у меня последний вопрос. Зачем вообще может понадобиться иметь несколько гвардов? В документации написано, что в конфиге можно добавлять свои: например admin. Например, два session гварда с разным названием. В чем практическая польза?
l4m3r, Мне кажется у вас обычное RPC апи, а не REST, и важно ли вам чтобы оно было stateless обычно должно обсуждаться отдельно (спойлер: 99% что в вашем случае, как и в большинстве, неважно)
P.s. Раз уж я уже влез: не бывает понятия "REST запрос", это звучит так же абсурдно как какой-нибудь "MVC запрос" или "SPA запрос"
Александр Аксентьев, извиняюсь что вклиниваюсь, но это "Потому как апи первоначально задумывалось как протокол для работы с другими серверами" полный бред и подмена понятий. REST API даже из расшифровки аббревиатуры обозначает управление состоянием через представление, и в 99% случаев это управление состоянием в клиентском браузере через html, и по поводу того что всякие умники REST'ом кличут любое апи возмущался даже Рой Филдинг у себя в блоге https://roy.gbiv.com/untangled/2008/rest-apis-must... .
Надеюсь, если мы говорим про rest, имя Роя Филдинга должно вам быть ближе чем некий Гаурав Кумар с quora
Евгений Ромашкан, почитал подробнее про REST/RPC. Но в RPC же я отправляю команду на сервер в определённом формате и получаю ответ. И там есть чёткие правила, которые у меня не соблюдаются. А у себя же хочу сделать все API пo HTTP GET/POST/PUT/DELETE. Да, знаю, что REST не должен быть ограничен HTTP протоколом, но это какие-то сферические кони получаются.
Есть пример истинного Restful, чтобы посмотреть?
l4m3r, SPA это и есть отправление на сервер команды/запроса и получение ответа в заранее определенном формате
Никаких особых правил нет, если мы говорим просто о протоколе RPC, а не о какой-нибудь более подробной спецификации как, например, JSON-RPC. Просто так следовать этим спецификациям смысла нет. Главное требование к АПИ - чтобы им было удобно пользоваться тем, кто им собирается пользоваться.
REST - это изначально набор архитектурных ограничений для клиент-серверных приложений. Там 6 обязательных и 7-ое необязательное. Наиболее подробно описана архитектура в диссертации, в которой и был введён этот термин - https://www.ics.uci.edu/~fielding/pubs/dissertatio...
REST предполагает довольно жесткие ограничения для обеспечения некоторых принципов описанных в диссертации. Один из них - scalability.
В народе есть довольно странная мода, называть "API" только взаимодействие через RPC. То, как работает браузер с серверами сайтов - тоже API. Это сейчас мы используя JS можем расширять возможности браузеров до огромных масштабов, и делать из них RPC клиентов.
REST предполагает что клиент ничего не знает о сервере кроме одной точки входа(ограничение "Starting with null style из диссертации"), и не знает куда слать запросы, REST клиент лишь умеет отображать какой-то стандартный заранее обговоренный набор форматов, как браузеры умеют отображать (ограничение "Uniform interface", хотя его понять сильно сложнее) html, jpg и т.п.
Так вот, то как работал Веб до того как из браузеров стали с помощью JS делать полноценные приложения и можно назвать примерами взаимодействия по REST API, в описании ограничения "Uniform interface" есть подпункт HATEOAS (Hypertext as the engine of application state). Суть в том что переходы состояния клиента полностью контроллируются со стороны сервера, и в примере с Web`ом всё довольно просто - переходы состояния клиента контроллируются через теги <a> и <form>. Вобщем, количество сайтов в интернете росло и растет стремительно, а никаких изменений в наш клиент(браузер), чтобы они работали вносить нет необходимости, миллионы сайтов мы посещаем используя один и тот же клиент, потому что у них единый "Uniform interface".
Вобщем, сумбурно описал, я хотел лишь сказать что нет смысла пытаться соблюдать какие-то ограничения только за то что они есть в REST, если для вашего приложения нет потребности в этих ограничениях. SPA приложения, или там, АПИ для мобилки это по сути всегда RPC, нет нужды пытаться назвать его по другому. Создавать свой REST клиент(по сути новый браузер) это долго, дорого, и для обычного приложения никогда не окупится )
Есть пример истинного Restful, чтобы посмотреть?
Да самый простой веб сайтик без JS-а)
Там будет и "Starting with null style", и "Client-server", и "Caching", и "Uniform interface". Единственное что, проблемы со stateless из-за сессий, и есть ли там " Layered System" мы на клиенте не узнаем )
P.S. И да, не смотря на то что "REST ignores the details of component
implementation and protocol syntax in order to focus on the roles of components", не удивительно что он так удобно ложитьсяна HTTP, автор термина REST (Рой Филдинг), в том числе и со-автор спецификации HTTP )
