Level 122
api routes do not use sessions or csrf - they are stateless
if you want sessions put your routes in web.php
Dec 17, 2021
6
Level 6
'Session not set in store': Is StartSession middleware needed in API? (solved)
I'm seeking some clarity and guidance about when I need to use sessions and use the StartSession middleware. I have some forms on pages that are behind auth. Submissions trigger axios requests (GET, POST, and PATCH) in api routes to interact with a database. Aside from csrf protection, these routes have no extra security or authentication. Yet in testing I see at least one of these submissions triggering a session not set in store error -- unless I have \Illuminate\Session\Middleware\StartSession::class in the api middleware group. The
Laravel default for this group does not contain this middleware.
My understanding of when sessions are needed is fuzzy. Why would a new session be required for one of these api routes doing an axios request to the server, when the user generating the request is already logged in? Should I put \Illuminate\Session\Middleware\StartSession::class in the global middleware group?
Level 16
Typical API endpoints are stateless, meaning the server does not hold any information about the endpoint's consumer. It also does not make sense anyway, because REST in essence is stateless. That's why the default configuration does not contain anything about cookies, CSRF, sessions.
Your use case of "API" is probably an extension to the existing application that is being served.
"when the user generating the request is already logged in" implies persistent state, and that very state has to be retrieved from somewhere: the session storage.
Take a look at this middleware from Sanctum: https://github.com/laravel/sanctum/blob/2.x/src/Http/Middleware/EnsureFrontendRequestsAreStateful.php
Level 6
thanks @snapey and @mabdullahsari Thanks, this helps.
Your use case of "API" is probably an extension to the existing application that is being served. "when the user generating the request is already logged in" implies persistent state, and that very state has to be retrieved from somewhere: the session storage.
Regarding my use case, I'm wondering now whether it makes the most sense to put the axios routes in the api group. This is not an SPA. It's an app that has a public side and an auth side where registered, logged-in users can do posts and edits to a database using axios calls. Maybe the current route and middleware setup ought to be done differently? Should all of these routes be in web rather than divide them between web and api?
Level 122
@pweil yes
1 like
Level 6
This is a followup. After a lot of consideration, I've put my ajax routes into api and set up Sanctum for api authentication (this is not an SPA). The application is running Laravel 6, Vue 2, and Vuex.
Scenario: users and admin can update a resource using an api route that uses ajax to send data to a mycontroller@update method for processing.
However, in the mycontroller@update method, different things can happen depending on whether or not the user is an admin. But -- please correct me if I am wrong -- the mycontroller@update method has no way of knowing who is making the request.
Question 1: if I am correct about this, what is my best option for conveying the user's status to this controller method? Add suitable parameters to the request? Or maybe use the Sanctum's EnsureFrontendRequestsAreStateful middleware?
Question 2: it seems under this type of setup, Laravel policies would have no effect on controller methods called via api routes. Session-based and token-based authentication seem to be two different worlds. Would it make sense to move these kinds of methods to some other controller, or protect them by some other means? Or doesn't it matter?
Level 6
Ok, I've got everything working now using Sanctum's middleware for api routes.
Please or to participate in this conversation.