Member Since 1 Year Ago
3,220 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.
Unfortunately in our case, we have to stick with Redis because the application must be as performant as possible at (hopefully massive) scale, and we want to minimize the workload on our PostgreSQL server.
I think the approach I outlined in my original post (keep Redis as the store, but write the session info to some SQL table every time a login or logout occurs) would work, I was just hoping there was some existing solution or easier way.
Those Redis methods look like they could be useful in some other contexts. In this case however, I'm not sure how they will help. Here's a Redis session key/value created when I logged in:
There don't seem to be any values there which tie the session to a
user_id. That's understandable of course, since even unauthenticated visitors will have a session.
But I don't see how we could directly query Redis to essentially retrieve all sessions belonging to X user.
Started a new Conversation Supporting Session Management When Session Driver Is Redis
We're using Redis as our session store in a Laravel 7 project.
In the user's account dashboard, we want to provide UI for managing their current sessions. (example)
I found this solution, but it requires the database session driver.
There's also hamedmehryar/laravel-session-tracker, but it hasn't been updated in a few years and fails to install on a fresh L7 project. I'm not sure it would work with L7 and/or Redis as the session driver, or if it's even an ideal solution in general.
At this point, it seems we may have to roll our own session tracking middleware/model/migration/etc., recording and tracking sessions in a SQL table. Roughly speaking:
Illuminate\Auth\Events\Logoutevents, then update our SQL db table with the session id (along with metadata such as device name, etc.).
Session::forget()on each session id and also delete those records from the SQL table
Was wondering if anyone else has encountered a session management requirement when using Redis as a session store, and how you handled it.
Replied to Best Approach To Extend Laravel Sanctum
the only thing Sanctum is really doing is creating a hash of a randomized 80-char string
I didn't mean that's the only thing it does. I know that most are interested in it for SPA authentication. I should have said "the only thing Sanctum is really doing to generate a new key." I meant that if we rolled our own, we would just copy that method and build around it.
I'm also unclear about how the abilities property works, especially if we're using something like spatie/laravel-permission to further determine what the API key is authorized to do.
It's not a problem if we have a non-standard authorization/permissions solution, right? Because we can simply put all of our custom authorization logic in its own middleware which would get hit after an API request gets through the
Started a new Conversation Best Approach To Extend Laravel Sanctum
We'd like to use Laravel Sanctum to issue API keys / personal access tokens for users, with some modifications:
AccessRestrictionwith each token, which is simply a model whose properties would define security-related authorization rules for the key (such as the HTTP referrer or IP address the request must come from).
personal_access_tokenstable, so we can store additional metadata for each token (or at least the id of some model where we'd store that, such as
I'm also unclear about how the
abilities property works, especially if we're using something like spatie/laravel-permission to further determine what the API key is authorized to do.
For the added DB table columns, I suppose we could simply override Sanctum's default migration.
And I assumed that we could create separate middlewares for authorizing based on referrer/IP and for checking against rate limits - then require all API requests to first go through the
auth:sanctum middleware for authentication and then those additional middlewares for authorization.
However, I'm a little fuzzy on how we would need to extend Sanctum and get all of this to work together, and just looking for some guidance.
There's an argument that we just roll our own key generation and management system. After all, the only thing Sanctum is really doing is creating a hash of a randomized 80-char string.
Thank you for any advice or guidance!