Member Since 1 Year Ago
2,960 experience to go until the next level!
In case you were wondering, you earn Laracasts experience when you:
Earned once you have completed your first Laracasts lesson.
Earned once you have earned your first 1000 experience points.
Earned when you have been with Laracasts for 1 year.
Earned when you have been with Laracasts for 2 years.
Earned when you have been with Laracasts for 3 years.
Earned when you have been with Laracasts for 4 years.
Earned when you have been with Laracasts for 5 years.
Earned when at least one Laracasts series has been fully completed.
Earned after your first post on the Laracasts forum.
Earned once 100 Laracasts lessons have been completed.
Earned once you receive your first "Best Reply" award on the Laracasts forum.
Earned if you are a paying Laracasts subscriber.
Earned if you have a lifetime subscription to Laracasts.
Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.
Earned once you have achieved 500 forum replies.
Earned once your experience points passes 100,000.
Earned once your experience points hits 10,000.
Earned once 1000 Laracasts lessons have been completed.
Earned once your "Best Reply" award count is 100 or more.
Earned once your experience points passes 1 million.
Earned once your experience points ranks in the top 50 of all Laracasts users.
@bugsysha No, I meant, I wanted to make several requests with different users who have different access levels. But thanks for the hint!
For sessions it also makes sense for me to. But not in this case with the stateless TokenGuard. I can only guess it's to enable the possibility to make assertions about the authorization.
@bugsysha Yeah, if there the two possibilities, it works. But not with more than one authenticated user (restricted, manager, admin...)
I understand what you say about the "reboot". I just wonder, that the request in the test is not encapsultated in such a way. I would not have expected a user to be logged in after I get a response from a stateless request.
Yes, I split them up. Was just trying not to clutter the tests to much and put it in one "only authorized users can..."
@bugsysha Yes, you should be able to replicate it.
I now went with splitting the tests.
@bugsysha I am indeed on a fresh install.
Ok, so up until now the solution has to be to split tests further to avoid this issue.
Since the TokenGuard is not stateful, it has no
logout() method. Still,
Auth::user() return true, or a user, respectively.
So the question basically is: Why isn't the authenticated state reversed after the request returns a response? Why is the user still authenticated via TokenGuard throughout the next test steps?
Is there any way to revoke the authentication manually in the test?
Started a new Conversation Subsequent Tests To API With Token Guard Do Not Require Auth Header
I'm testing an API with a token guard. When I make a request (
this->getJson()), I provide the api token as a Bearer token in the
Authorization header. Subsequent requests without the header also pass as authorized.
Isn't token authorization meant to be stateless? Even
$this->flushHeaders() does not change the behavior. From a request without
Authorization header I would expect to return a 401, not a 200. But it seems like the header on the first request is "re-used".
Could anybody please explain this behavior? Am I getting something wrong here?
Awarded Best Reply on PHP CS FIxer
@xtremer360 If you include it in the single project repo, all contributors can use a consistent style.
At the end, I think, it does not matter that much, if all projects follow the same style, but that each project has a consistent style for itself.
I just read for the first time about
From the docs:
$books = App\Book::without('author')->get();