Is it possible to log out a user after a certain amount of time in Sanctum stateful mode? For example the user will be logged out after 4 hours or at the end of the day.
I know that you can set the expiration date for API tokens but I want to log out the user after a certain amount of time in stateful mode (session-based auth).
To clarify, ANY user should be logged out after a certain amount of time. Like you see it in bank applications or other websites with greater security.
In .env you have a variable called SESSION_LIFETIME. That is stored in minutes. Change it in 240 if you want autologout on 4 hours
Related
I am using Laravel 8 AUTH package. Once user is login and if he idle for 15 min. then auto logout user and redirect to main website page.
or how to write corn job for it for I am doing corn job like below in 15Update.php corn script
but nothing happen.
You can change the lifetime in the config/session.php file to 15 min.
If you want to accurate time with idle time, you must handle it via the log table in the database.
If you want to handle it via package and middleware, please read this article.
I have register/login with SMS on my website. I want to limit number of tries by a user for register or login attempts. They should be able to try 20 time per day for registering or login to website.
What is the best way to impelement this? I have tried using
laravel throttle middleware
cookie and ip address of user
to count number of tries.
which one should i stick to? or there is better solution?
The throttle middleware was built exactly for this, so I would stick with that. The 20-times per day limit could be counted on the User model. You would need to schedule a cron job to reset it to 0 after 24h, though. For more info on rate-limiting, see the documentation.
I have site on Asp.Net Core 2.2 using Sessions.
Is there any way to get all users sessions, and all login users and iterate them?
Also break session for some user, if he is banned.
Simply, no. A user's authenticated state is persisted only via a local cookie on the client. There is no sort of "master list" of logged in users. However, if you like, you can create an additional table or otherwise log user logins and logouts, which you can then refer to for this information. It won't end up being totally accurate, particularly with logouts, because the user's auth could simply timeout, requiring no action that you could tie into to log that that that happened. However, if you have a known auth expiration, say 20 minutes, you can assume any login older than that time frame is no longer valid. That assumes an absolute expiration, which is the default. If there's a sliding expiration, you'll need to do even more work to keep some sort of user activity record.
Long and short, it's not trivial, but can be done if you really need the information.
As far as auto-logouts go, that merely requires invalidating the security stamp. This will effectually invalidate the user's auth cookie, forcing them to have to login again. At that point, you can check their "banned" status, however that would be done, and opt to reject their login attempt.
await _userManager.UpdateSecurityStampAsync(userId);
However, that will not take effect immediately, since the security stamp is not revalidated with each request. You can make that happen by setting the validation interval to zero in Startup.cs:
services.Configure<IdentityOptions>(options =>
{
options.SecurityStampValidationInterval = TimeSpan.FromSeconds(0);
});
However, that has a performance cost, as each request will require hitting the database to check the security stamp. You may want to set a more reasonable interval that balances wanting to logout a banned user as quickly as possible without requiring making excessive database requests.
I am having troubles to understand the login flow and signup flow in PassportJS and ExpressJS.What I really wanted to do is test if different sessions are being created. So I opened up a server and open two windows both at login pages. and then I log in and a session is created, but it is created for only person i.e. one who enters last, in my sessions table there is always one entry. Is this the expected behavior or is this wrong? How can I test this behavior in real time i.e. logging in 20 users and see 20 entries in my sessions table?
it depends on how you are handling sessions, most likely cookie, in which case you may need to refresh the browser, if that doesn't work. You're cookie expire date may not be set properly or you may not be deserializing properly. Read this for reference: https://scotch.io/tutorials/easy-node-authentication-setup-and-local
I'm a nowise in ZF2 and need an advise from more experienced users.
I'm developing a small shop I want to make different lifetime for session storage and cookies.
For example when user logins server sends a cookie with 3 months lifetime and creates session storage record (for user data) with lifetime 30 minutes. Having cookie and unique session record user can buy goods, comment, and view their profile with secure data (e.g. credit card number, phone, etc).
After 30 minutes of no activity session record must be deleted but cookie must be left (cookies lifetime must be 3 months). Having only cookie user can make comments but can not buy anything or view his/her profile.
So my I'm interesting how can I realize it with ZF2 ? - As I understood "remember_me_time" must be equal to "cookie_lifetime" or they can be changed to different values ?
Does ZF2 have any standard mechanism to delete a session storage after some time for single user or I have to create such mechanism by myself ?
If you're using ZfcUser (and if you're doing user authentication on ZF2 you should be) check out the GoalioRememberMe(https://github.com/goalio/GoalioRememberMe) module, it does exactly what you're looking for (Caveat: I've never actually used it myself so I can't vouch for it's efficacy or security)
I also suggest reading this response by Anthony Ferrara (#ircmaxell) to a somewhat similar question. It contains some background information on what you should and shouldn't do, and the gist of it is: don't try to keep the PHP session open that long, use a "remember me" cookie instead and build a new session from the remember-me cookie for visitors that don't have an active session.