- Apache Solr
- Development Principles
- Microsoft .NET
- Microsoft Office
- Social Media
- Spring 3.0
- Spring Roo
- Symfony: Doctrine
- Symfony: View
- Symfony: Web Services
- Transact SQL (T-SQL)
The lifeblood of our business is that R&D spend. There's nothing that flows through a pipe or down a wire or anything else. We have to continuously create new innovation that lets people do something they didn't think they could do the day before.
Symfony: Session Login Timeout
Data and locations
Symfony uses the PHP session management sub-system to store tempoary user specific data. When using the sfDoctrineGuardPlugin, or any other application guard, the timeout and lastRequest data are stored. You can find this data in the following places:
- lastRequest - /var/lib/php/sess_*. files (note this location is defined in your php.ini file in the session.save_path setting. Under Debian the php.ini file is found at /etc/php5/apache2/php.ini)
- timeout - by default set by the sfBasicSecurityUser to 1800 however can be controlled in the factories.yml file using the below configuration
# ./apps/<application name>/config/factories.yml all: user: param: timeout: 14400
This will instruct the sfBasicSecurityUser to timeout the session after 4hours. This is done by testing the lastRequest session variable with the timeout variable. Symfony will only set this value if it is greater than the PHP value. Read below.
PHP Session Management
When using sessions under 24min all that is needed is setting the factory file. However because PHP uses files, by default, to store session data, PHP needs to clean up these file. This is done by way of a cron script (/usr/lib/php5/maxlifetime) that runs ever 30minutes (/etc/cron.d/php5) and deletes all session files that are older than php.ini:session.gc_maxlifetime (default 1440 (24minutes)).
Since PHP has no clue of Symfony it will happily delete all session files that are older than the gc_maxlifetime value. This causes Symfony to logout the user. The user then has to login again. For all "day long apps" that are only used periodoticly (like time tracking software) this can cause some greif for the user.
The simple solution is to change the default gc_maxlifetime value to something larger than your symfony user timeout value. i.e.
If your using the Symfony default session timeout (30min) then set the session.gc_maxlifetime = 1800
If your using the factories.yml:/env/user/param/timeout then set the session.gc_maxlifetime equal to the factories.yml:/app/user/param/timeout value
So here is the psudo code in sfBasicSecurityUser
symfonyTimeout = factories.yml:/env/user/param/timeout phpTimeout = php.ini:session.gc_maxlifetime if symfonyTimeout is greater than phpTimeout then increase phpTimeout end if // and here is the problem with PHP and the file deleation // The file wont exist if PHP has deleted it and the // lastRequest will be older than timeout if file exists /var/lib/php/sess_* lastRequest = /var/lib/php/sess_*:lastRequest else lastRequest = 0 end if if lastRequest older than phpTimeout then logout the user end if
If you found this article useful, please be sure to check out the related articles below.
Add a comment