I'm currently using Laravel 5.6 with the Laravel JWT library for a new web app.
I would like to store the JWT in a cookie without using a conventional session but there doesn't seem to be an easy way of going about this with the JWT library.
In my Auth controller I return the token in a cookie, but Laravel still starts a session which I don't want since I want the session inferred from the cookie.
I also went into Kernel.php and removed some of the Session stuff from the web middleware group but then that caused a runtime exception saying "Session store not set on request."
I've seen some hacked together solutions that were half implemented, but I would like hear some insight from anyone that has done this elegantly or felt like their solution was correct.
Thanks
For my purpose I determined that using encrypted cookies will suffice for the web application (using Redis as a cache), and then using JWTs for the mobile API.
Related
I am working on a react native application for a website which is made in Laravel so all of its APIs are based on Laravel.
I am facing a problem of CSRF token when making POST request to the Laravel Backend. Every Time I am getting a response of Page is Expired.
I have done some research on the issue and found that CSRF tokens are generated by Laravel by default for security purposes. My question is how can I connect to Laravel API.
One solution which was suggested is to use JWT tokens but that's really not a feasible solution for me and I am not sure how to implement JWT Authentication in Laravel.
Another Solution which I have read is that whenever we visit a page made using Laravel then in window object window.csrfToken can be accessed which is the token I need for making the API calls. Is it true? and if it is then how can I get that in React Native Application (should I make a GET request for the website and try to get the token from there is it possible?)
One more solution I think is that we can bypass some routes in Laravel Middleware so that token is not checked.
I need some suggestions on the issue. Also need to know that above solutions are correct or not and which one should I use.
Thanks
Super strange issue.
I have SPA Nuxt JS app and Laravel 8 API to power it.
I got the Sanctum to authenticate my SPA but here is the deal - on page load before you log in I am making 3 API calls to get some data to display. Now these three calls they all set XSRF cookies and they all create sessions in Laravel session directory.
After that it uses one of these sessions but I do not understand why the call to data endpoint would create extra session?
These are API endpoints in the API routing file, and do not have any unusual stuff there. Any ideas what could it be?
To my understanding I should not get any session for that!
I've dropped exact config I am using in description of related problem right here: Laravel API (Sanctum) + nuxt auth - weird cookies behaviour, I don't get it
Am trying to build secure login for my small app so i decided to use JWT approach by using JWT firebase library for lumen,
i discover i cant revoke my token except some dynamic data like session. And Lumen has stop shipping with session package since lumen 5.2,
i know there might be a reason why they stop supporting session .
And i have Tymon JWT package but it does not work well with lumen 5.6.
That why i use Firebase JWT-PHP as alternative
I will like to know alternative for session with strong example or any idea of best JWT login with revoke of token on logout
If you want to use sessions, the method in this comment seemed to do the trick, though I haven't torture-tested it all that much (I just discovered it a couple days ago myself), so YMMV:
https://stackoverflow.com/a/47055083/1246105
In short, you can just ala-carte install the session-handling from Laravel.
Since the last version (5.2), cookies are disabled in Lumen. I'm currently making an API in Lumen with JWT authentication.
To secure my application from CSRF attacks I need to set a csrf cookie. But what is the best way to handle that now?
VerifyCsrfToken Middleware was removed in this commit.
From Lumen 5.2 documentation:
Lumen 5.2 represents a more decided shift towards focusing on stateless APIs.
So, if you need Csrf Token verification, you have to implement it storing it in a meta tag or inside a JWT payload as a private claim (you will need to implement the new claim, i.e.: here).
If it was removed, there's probably a good reason. Here I let some links that maybe can help you move on.
CSRF Token necessary when using Stateless(= Sessionless) Authentication?
Where to store JWT in browser? How to protect against CSRF?
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage#post-2748616172
I do receive a chalenging task to migrate a old legacy cakephp 2 app to laravel 5.2.
The two must coexist and work togheter, while all modules are migrated to laravel because it is a large app.
Is it possible/feasible? the auth session credentials can be transported to laravel auth session easily?
What kind of traps you can find int this proccess? and how can i avoid them?
I have only found these steps : http://laravel.io/forum/09-08-2014-strategy-for-migrating-a-large-cakephp-project-to-laravel?page=1#reply-28620
Anyone already done this before ?.
The by far most logical solution would be to transfer the entire application over to Laravel at once. However, if that's not a possibility, it should still be possible. If you keep sessions in Redis, they'll of course be accessible by both applications. The main issues might be:
You want a User object on the Laravel app to authenticate, but authentication happens in the Cake app. Hence, you might need to reauthorise somehow in the Laravel application. However, if you know the session is valid and you have the user ID, you can do this without issue.
The session token is generated differently: Laravel will generate its token through one algorithm, using its application key. Without any knowledge of CakePHP, I'm confident the session key is generated differently. You might be able to surpass this by modifying the generation of the key for them to match. Otherwise, you'll end up with issues for hashing salts, CSRF verification and whatnot if those things go between the applications.