Bug #13178

Possible PHP regression: cannot log in with Debug mode enabled when using PHP 7.2

Added by Dan Gillean over 2 years ago. Updated almost 2 years ago.

Status:FeedbackStart date:09/18/2019
Priority:MediumDue 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
Error encountered
  • 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.

PR for CR: https://github.com/artefactual/atom/pull/1018

#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

  1. The default apps/qubit/config/factories.yml file uses QubitCacheSessionStorage for the production config, and sfSessionStorage for the development config
  2. The qubit_dev.php controller uses the dev config, whereas the default production controller index.php uses the production session config
  3. The PHP session ids set in QubitCacheSessionStorage contain a colon (e.g. "32148ff1dadefff286e1c1a6d077b2d0:e413f6fc151ce92549c88664df11f621196e056e"), but the sfSessionStorage uses PHP's default file storage for sessions, and for PHP file storage session ids the colon is an invalid character
  4. 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 production index.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.

Also available in: Atom PDF