Bug #13178
Possible PHP regression: cannot log in with Debug mode enabled when using PHP 7.2
Status: | Feedback | Start date: | 09/18/2019 | |
---|---|---|---|---|
Priority: | Medium | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Internals | |||
Target version: | - | |||
Google Code Legacy ID: | Tested version: | 2.5, 2.6 | ||
Sponsored: | No | Requires documentation: |
Description
I've encountered an issue with our Debug mode while testing in the AtoM Vagrant box. Steve could not reproduce the issue on an older box using PHP 7.0, but Corinne could reproduce it in her 7.2 box. Essentially, logging in doesn't work when debug mode is enabled in AtoM.
To reproduce in an installation using PHP 7.2
- Make sure you can access qubit_dev.php - you may need to add your IP to /etc/php/7.2/fpm/pool.d/atom.conf
- If you edit this configuration file and add your IP, be sure to restart PHP-FPM after
- Open AtoM in the web browser
- Add qubit_dev.php to the URL
- Attempt to log in
- AtoM reloads the page but will not log the user in
Expected result
Users can log in while Debug mode is enabled
History
#1 Updated by Mike Cantelon over 2 years ago
- Status changed from New to Code Review
Deleting cookies seemed to have fixed it.
I got rid of a bunch of PHP 7.2-related warnings, though.
#2 Updated by David Juhasz almost 2 years ago
- Status changed from Code Review to Feedback
I've had the same problem of not being able to log in with the qubit_dev.php
front-end controller in the AtoM 2.6 vagrant box. I've tracked down the source of the problem, and I've added what I've discovered below.
Problem
- The default
apps/qubit/config/factories.yml
file usesQubitCacheSessionStorage
for the production config, andsfSessionStorage
for the development config - The
qubit_dev.php
controller uses the dev config, whereas the default production controllerindex.php
uses the production session config - The PHP session ids set in
QubitCacheSessionStorage
contain a colon (e.g. "32148ff1dadefff286e1c1a6d077b2d0:e413f6fc151ce92549c88664df11f621196e056e"), but thesfSessionStorage
uses PHP's default file storage for sessions, and for PHP file storage session ids the colon is an invalid character - The code that loads digital objects for display in the information object browse and view pages, strips
qubit_dev.php
from the URLs that load the digital objects, which causes the requests to be loaded by the productionindex.php
front-end controller
The end result is that when the digital objects are loaded in the information object browse or view pages, the index.php
controller is used, which forces the AtoM session_id to be regenerated with a colon. When the qubit_dev.php
controller then tries to load the session, it fails because of the invalid colon character:
PHP message: PHP Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /usr/share/nginx/atom/vendor/symfony/lib/storage/sfSessionStorage.class.php on line 94
Because the user session isn't loaded, the user is treated as unauthenticated.
Solutions
The easiest work around for the problem is to use the same session storage class for both the production and development configs by updating apps/qubit/config/factories.yml
. After updating the configuration, the symfony cache must be cleared, and php-fpm and memcached should be restarted. It may also be necessary to delete the existing session cookie from your browser to get a session_id that is valid for the sfSessionStorage
class.
I think the best solution to the underlying issue would be to modify the routing and digital object view code for doing ACL checks on digital objects (via "X-Accel-Redirect" in Nginx, or "X-Sendfile" in Apache) so qubit_dev.php
is persisted in digital object URLs so the dev and prod contexts are not mixed in the page requests. However, updating the current code to load digital objects is tricky because the configuration to implement the digital object ACL checks is complex, and involves routing, Nginx config, and PHP code changes.