For example, if your goal is to track a channel that brought the user to the site you could simply store that channel information in their cookie instead of the $_SESSION. That way your sessions table stays lightweight and you can still do tracking of the user inside the cookie. However, you might consider if you can instead store the data in the cookie instead of in the session. If you truly need to store session data for 2 years that's fine. The other class of users who got deleted after 3 months would be deleted in a job that ran overnight as it performed more operations and had more impact on server resources. For my scenario, 1 class of users who had not been active in the last hour were logged out so that job ran every hour. You can even run the select against a read-replica database to reduce the performance impact further. This had the greatest performance while having minimal impact. Instead, I wrote a loop that would find records to delete and then run individual delete queries with a condition WHERE sid = :sid so it was using a primary key. I found that trying to do a sql delete directly does not scale well. Saving the cookie data beyond that for what amounts to a rounding error is generally not super useful. 95% were within the first week and going out to 3 months got up to 98%. 90% of users who committed and got engaged did so within the first day. That said, I also found that user interaction followed a power-curve. The limit of your sessions table depends on database server hardware, but my experience on a fairly large site is that you can have millions of sessions records and it's not a huge problem for performance. According to system.install, that column contains The Unix timestamp when this session last requested a page. in drush) that will find stale sessions and delete them.įor item #2 for you that means it has to find the Internal users with a short lifetime and delete their session if the sessions.timestamp is beyond a limit. Set the cookie lifetime and server session timeout to the larger of the 2 numbers, in your case I guess that's 2 years.I have achieved this goal in the past for Drupal 7 using a bit of custom code. assuming I can set the server session, how can I have the cookie lifetime visit based on user role? I'm getting to the point where it seems like it just might not be possible to vary this setting, and I might have to do some kind of route subscriber and custom cookies and whanot to detect the internal users, and log them out when I see they've been logged in too long. What if it's not 1 year, and I want it at 2 years? I can't seem to find a definitive guide to what the upper limit of server session should be? It seems like there's a lot of factors that could clear out that session as well. One of my questions is: what are the risks/downsides/etc to setting my server session to 1 year? Let's say my server gets 50k visits a month. If I want my user to be logged in for 1 year, I need my server session to be 1 year. So, I think I have to start with the upper limit. If I set the cookie lifetime to 1 week, but the session lifetime is 1 day, the user will essentially be logged out after 1 day, b/c their cookie will match a session that doesn't exist after a day. ![]() there is the cookie lifetime of a user, and the session lifetime (on the server). My understanding of the Drupal login is that there are really two things controlling this. ( Note: I didn't make these requirements, just coding them. ![]() ![]() Internal users need to be logged in for a short period of time, say 1 day, or even just the session. The request is to have Clients logged in for an indefinite period of time. I'm going to attempt to simplify the requirements. ![]() * Event subscriber subscribing to KernelEvents::REQUEST.So I have a requirement that I'm getting close to stumped on how to complete in Drupal 8. Use Symfony\Component\EventDispatcher\EventSubscriberInterface Use Symfony\Component\HttpKernel\Event\GetResponseEvent Use Symfony\Component\HttpKernel\KernelEvents Use Symfony\Component\HttpFoundation\RedirectResponse namespace Drupal\mymodule\EventSubscriber Then add RedirectAnonymousSubscriber.php for your custom event subscriber in your module in the /src/EventSubscriber/ folder. You can test a user's status very early with event subscriber in a custom module that subscribes to KernelEvents::REQUEST.įirst, you register the event subscriber in in your module folder: services:Ĭlass: Drupal\mymodule\EventSubscriber\RedirectAnonymousSubscriber
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |