Page MenuHomePhabricator

Redirect loop on fresh installation
Closed, InvalidPublic

Description

Similar to T9469. On a fresh installation with the database set up with unprivileged db user, I get a redirect loop to '/auth/register/'. After setting debug-stop-on-redirect to true, I got the following:

Depth	Library	File	Where
6	phabricator	applications/auth/controller/PhabricatorAuthStartController.php : 65	AphrontRedirectResponse::__construct()
5	phabricator	aphront/AphrontController.php : 71	PhabricatorAuthStartController::handleRequest()
4	phabricator	applications/base/controller/PhabricatorController.php : 191	AphrontController::delegateToController()
3	phabricator	aphront/configuration/AphrontApplicationConfiguration.php : 224	PhabricatorController::willBeginExecution()
2	phabricator	aphront/configuration/AphrontApplicationConfiguration.php : 149	AphrontApplicationConfiguration::processRequest()
1		/srv/www/vhosts/phabricator.cynistar.net/live/phabricator/phabricator/webroot/index.php : 17	AphrontApplicationConfiguration::runHTTPRequest()

Also, when hitting bare domain URL, I get:

Request parameter '__path__' is set, but empty. Your rewrite rules are not configured correctly. The '__path__' should always begin with a '/'.

I had to precede all the Apache RewriteRule directives with RewriteCond %{ENV:REDIRECT_STATUS} ^$ because the app was constantly redirect looping even before I got to this point. I thought I had that nonsense sorted out but apparently not.

Stripped bare, the Apache config is:

<VirtualHost *:80>
    ServerAdmin webmaster@example.net
    ServerName phabricator.example.net
    DocumentRoot /srv/www/vhosts/phabricator.example.net/live/phabricator/phabricator/webroot
    LogLevel debug
    ErrorLog /var/log/apache2/phabricator.example.net-error_log
    CustomLog /var/log/apache2/phabricator.example.net-access_log combined
    HostnameLookups Off
    UseCanonicalName Off
    ServerSignature On
    <Directory "/srv/www/vhosts/phabricator.example.net/live/phabricator/phabricator/webroot">
        RewriteEngine on
        RewriteCond %{ENV:REDIRECT_STATUS} ^$
        RewriteRule ^/rsrc/(.*)     -                       [L,QSA]
        RewriteCond %{ENV:REDIRECT_STATUS} ^$
        RewriteRule ^/favicon.ico   -                       [L,QSA]
        RewriteCond %{ENV:REDIRECT_STATUS} ^$
        RewriteRule ^(.*)$          /index.php?__path__=$1  [B,L,QSA]
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

FWIW, the LAMP setup this is running on has been in production successfully for several years, so it's unlikely to be a problem with the server, just with the app or this specific virtual host config. The virtual host config is essentially identical to the other 20+ on the system and there's not much to it aside from the rewrite rules pulled straight from the configuration guide.

Any hints on how to knock some sense into mod_rewrite?

Event Timeline

I'm not able to reproduce any issues installing Phabricator. Can you provide reproduction steps, specifically?

On a fresh installation

Did you follow our guide or another guide on the web?

I followed your guide. I ran the ubuntu installation script, followed the instructions for setting up the db, but even before then, the web app was redirect-looping with just those three RewriteRules in place. The REDIRECT_STATUS hack was the only thing that seemed to fix the initial looping but it's not catching the /auth/register loop.

How can I reproduce what you've done to get the same error?

chad renamed this task from Repeat of T9469: Redirect loop on fresh installation to Redirect loop on fresh installation.Feb 9 2016, 5:19 AM
chad updated the task description. (Show Details)

(if it helps, this is my virtual host config).

# Ensure that Apache listens on port 80
NameVirtualHost *:80

<VirtualHost *:80>
    DocumentRoot /Users/chad/Sites/phabricator/webroot/
    ServerName phab-dev.macbook.local
    
    RewriteEngine on
    RewriteRule ^/rsrc/(.*)     -                       [L,QSA]
    RewriteRule ^/favicon.ico   -                       [L,QSA]
    RewriteRule ^(.*)$          /index.php?__path__=$1  [B,L,QSA]

</VirtualHost>

I'm not sure that will work here; I'm running Apache 2.2. Older, sure, but completely capable of handling redirects correctly. If Apache 2.2 is too old, that needs to be listed as a system dependency up front.

What are the next steps needed to diagnose this system so the root cause of this misconfiguration or bug can be identified and resolved?

Also "Fishing Expedition"? That's a bit ... insulting. More than a bit, actually.

Also "Fishing Expedition"? That's a bit ... insulting. More than a bit, actually.

Oh, sorry. It's not intended to be. It's how we're testing subprojects. I'll rename it for clarification. Thanks for pointing that out.

I'm not sure that will work here; I'm running Apache 2.2.

Which versions specifically? We support 2.2 per documentation. If you have other versions that would help build a reproducible case, it might be helpful (OS, PHP, Apache).

What are the next steps needed to diagnose this system so the root cause of this misconfiguration or bug can be identified and resolved?

At best we can try to improve our error messaging (or documentation), which is intended to convey that the webserver has not been set up correctly for passing the path variable to Phabricator. This points to an issue at the webserver configuration level, and there isn't anything more in Phabricator we can do to resolve or diagnose this.

Path validation occurs very early in the stack, it's a simple check, did you pass us a path or not. The error you're hitting is "not". https://secure.phabricator.com/diffusion/P/browse/master/support/PhabricatorStartup.php;55f607e397e0b240de5518ad0374b591628e2296$532-556

I can't reproduce this either: I've created a new dm namespace, with no users, and navigated to / - that sent me to /auth/register/, no redirect loop.

The fact that you had to add RewriteCond %{ENV:REDIRECT_STATUS} ^$ implies some redirect loop inside the apache, before phabricator shows up?

@bob.apthorpe Poor sense of humour on our part aside, what else can we do to help you here? Do you have more specifics on reproducing the bug you can share with us? Unfortunately no one is able to reproduce with the steps you've provided and we have no other reports of issues with installation (T9469 was also a http configuration issue). Your twitter posts seem to indicate this server may not be directly under your control? Can you test in another environment or VM?

One final idea: Let's just take Phabricator completely out of the equation, assuming you followed our installation guide.

  1. Delete the contents of /phabricator/
  2. Add back /phabricator/webroot/
  3. Create index.php with the contents <?php var_dump($_REQUEST); ?>
  4. Navigate to your install. You should see array(1) { ["__path__"]=> string(1) "/" }
  5. Navigate to /cows/ on your install. You should see array(1) { ["__path__"]=> string(6) "/cows/" }

This is the smallest set of steps I can think of, taking out Phabricator completely, and leaving just Apache/PHP. This should tell us where next to look for issues (Phabricator or Apache/PHP).

epriestley claimed this task.
epriestley added a subscriber: epriestley.

It looks like the reporter has moved on for other reasons:

Phabricator looks good too but it requires a dedicated host name and since I don't control DNS, it fails too.
https://twitter.com/arclight/status/697503630778310656

See also this warm thanks for our efforts, meager and inadequate though they may be:

https://twitter.com/arclight/status/697475794352922625

chad changed the task status from Wontfix to Invalid.Feb 11 2016, 2:23 AM

Technically, this is "Invalid" as steps to reproduce the issue outside of the user's environment have not been provided, see Contributing Bug Reports for more information for what we take as a valid bug report. If a reproducible steps are provided and verified, we're happy to re-open and fix any issue in Phabricator or in the Documentation.

Specifically all we currently have for steps to reproduce are:

  • Apache 2.2 (ish)
  • Followed our guide
  • Used the ubuntu script

Based on those steps, we've not been able to reproduce any error. More information is needed. Hence the tag of "Fishing Expedition" which literally, according to Google, means "a search or investigation undertaken with the hope, though not the stated purpose, of discovering information.". We simply had hoped you would provide us with more information.