You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|*Cookie values for creation and expiration dates*|
106
106
107
-
By default is set with 2,000,000 seconds, equals to almost 24 days. See the previous caption with creation and expiration date, so for a cookie created on March 27th, we can see an expiration date of April 19th, which is just a 23-day life cycle, the marked 2,000,000 seconds.
107
+
By default is set with 2,000,000 seconds, equals to almost 24 days. See the previous caption with creation and expiration date, so for a cookie created on March 27th, we can see an expiration date of April 19th, which is just a 23-day life cycle, the marked 2,000,000 seconds. You can think about change this data in service.yml files, but It's true that these kind of files is out of control for Git so your changes will not be shared with your team, and it won't be recreated in common environments (stage, preprod, prod, live, etc). You'll need a more "structural" and persistent solution, so we will need to create a new custom module in next steps.
108
108
109
109
## Addressing session cookie management in Drupal
110
110
@@ -160,10 +160,7 @@ public function alter(ContainerBuilder $container) {
160
160
}
161
161
```
162
162
163
-
164
-
165
-
A new custom Drupal module has been implemented for alter the session data: st_session_manager, available in branch
166
-
163
+
Here you can see and download [the custom module implemented as example and uploaded to my Gitlab repository](https://gitlab.com/davidjguru/drupal-custom-modules-examples/-/tree/master/custom_session_manager). Check out the code and test the feature! (not for production - live environments, please).
And just enabling this new custom module, you will have a key change here: now the max-age of the session cookie will be set for expiring by session, see:
176
+
177
+
| |
Now when you close your browser, the session cookie will be deleted, the user logout will be executed and on the next URL load, the user session will still be closed.
182
+
183
+
184
+
185
+
## Session data & Garbage Collector & Cron
186
+
187
+
You can load the session time with the values you want. But this only let available the session data for the Garbage Collector of Drupal/PHP. It means that from 1 hour the session can be opened until the Garbage Collector was executed. Who’s executing the Garbage Collector? essentially, the cron in system. The “Automated Cron” core module can be enabled and set to 1 hours. It means that really, the inactive sessions (more than 1 hour without activity) will be deleted every 1 hour now, just when cron runs and launches the Garbage Collector.
188
+
189
+
But perhaps, we need a little more "granularity." that is, to launch the cron only for these specific tasks, because launching it completely and for everything very frequently may not be the good idea we were thinking of. We need to be able to filter tasks associated with the cron in a more atomic way. For this we can rely on certain Drupal contributed modules that can provide us with functionality.
190
+
179
191
180
-
Session data & Garbage Collector & Cron
192
+
### Useful Modules
181
193
182
-
The time for session was set to 1 hour. But this only let available the session data for the Garbage Collector of Drupal/PHP. It means that from 1 hour the session can be opened until the Garbage Collector was executed. Who’s executing the Garbage Collector? esentially, the cron in system.
194
+
Useful Drupal contrib modules we can use for more control over the session timing, roles and garbage collector from cron executions:
183
195
184
-
The “Automated Cron” core module was enabled and set to 1 hours. It means that really, the inactive sessions (more than 1 hour without activity) will be deleted every 1 hour now, just when cron runs and launches the Garbage Collector. Useful Drupal contrib modules we can use for more control over the session timing and roles:
196
+
1. Session Limit: [drupal.org/session_limit](https://www.drupal.org/project/session_limit). You can limit the number of sessions available for a role / user in different environments.
197
+
198
+
2. Automated Logout: [drupal.org/autologout](https://www.drupal.org/project/autologout). You can configure sessions settings values in order to force the logout in users.
Futhermore, we can create some specific cron-tab tasks on the server by prompt, if we need more control over the session data. Cron is a time-based job scheduling daemon in Linux Operating Systems. You can learn more about how to configure tasks in background using cron here:
191
204
192
-
Set values in order to force the logout in users.
205
+
*[How to setup cron jobs in Ubuntu](https://www.geeksforgeeks.org/how-to-setup-cron-jobs-in-ubuntu/)
206
+
*[How To Use Cron to Automate Tasks on Ubuntu](https://www.digitalocean.com/community/tutorials/how-to-use-cron-to-automate-tasks-ubuntu-1804)
207
+
*[How to Automate Regular Tasks with Cron on Ubuntu](https://serverspace.io/support/help/automate-tasks-with-cron-ubuntu-20-04/)
0 commit comments