Problem/Motivation

It was recommended with SA-CORE-2012-003 that the install.php could be deleted.
see Notes section on https://heine.familiedeelstra.com/drupal-7-installer-vulnerability

From the codebase it seems the bug is still present in Drupal 7.
https://git.drupalcode.org/project/drupal/-/blob/7.x/includes/bootstrap....

And it seems D9 is also redirecting without checking if the file exists.
https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/lib/Drupal/C...

Original Report

I've read everything starting from http://groups.drupal.org/node/121064 ( How to documentation for creating Drupal 7 multisite configuration ) about multi-site installation and I have two Drupal 6 installations working perfectly with multi-site but for the life of me I can't get a working version using Drupal 7.
The installation steps I followed were basically the same as for Drupal 6.
Whenever I attempt to navigate to a parked domain the browser eventually displays "This web page has a redirect loop" Error 310 (net:: ERR_TOO_MANY_REDIRECTS) There were too many redirects.
Please could someone tell me what I need to do to fix it?

Do I need to do some work with symlinks? They weren't needed in my Drupal 6 installations.

Steps to reproduce

For Drupal 7
1. Installed Drupal via Installatron
2. Configure a multisite install
3. Run Setup to create the multisite install

Proposed resolution

Delete core/install.php

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

herb_miller’s picture

herb_miller CreditAttribution: herb_miller commented
Status: Active » Closed (fixed)

I have found the culprit.

I installed the site using Softaculous. I was unaware that my hosting company had changed the installation from the default; install.php was not part of the installed software.
Had I thought about navigating to install.php in my home site I would have seen a 404 error.
So I copied install.php and everything started working.

Of course I didn't do this until after I'd manually created a completely new working multi-site installation using two other domains then compared the installations file by file, using BeyondCompare.... at which point the problem was blindingly obvious.

Perhaps there is some scope for improvement - the redirect should not be performed if install.php is not present.

limelightinternet’s picture

limelightinternet CreditAttribution: limelightinternet commented

Thank you. This post just saved me hours of frustration.

miguel’s picture

miguel CreditAttribution: miguel commented
Title: Redirect loop: Error 310 ERR_TOO_MANY_REDIRECTS for multisite install » Redirect loop if install.php is not present in a multisite install
Category: support » bug
Priority: Normal » Major
Status: Closed (fixed) » Active

This bug is marked as fixed but the problem remains on the latest Drupal. I reopen it.

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr commented
Version: 7.0 » 7.x-dev
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)

@miguel - can you please post detailed steps on how to reproduce this behaviour? Contributor doc on posting steps to reproduce:
http://drupal.org/node/1468198

It's not clear to me whether this happens when you are trying to install another site in a multisite install or whether it occurs after site installation.

Downgrading status per http://drupal.org/node/45111, I don't think this is a major bug.

miguel’s picture

miguel CreditAttribution: miguel commented

To reproduce

1. Installed Drupal via Installatron
2. Configure a multisite install
3. Run Setup to create the multisite install

Now the described error occours because the Installatron-Script removes install.php.

What I would expect

At least a message that install.php does not exist on the server.

To fix

Copy install.php to the server.

Status justification

I changed the status to major because this makes a multisite installation impossible. I guess most people will give up when having this error.

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr commented

Installatron? http://installatron.com?

Sounds like Installatron not removing install.php would fix this issue :)

star-szr’s picture

star-szr
he/him
Primary language English
CreditAttribution: star-szr commented
Version: 7.x-dev » 8.x-dev
Status: Postponed (maintainer needs more info) » Active

Just re-read the issue, I guess Installatron and Softaculous both do this so maybe it's worth considering.

To account for this behaviour in Drupal, we'd need to do something like check file_exists() before trying to redirect to install.php in _drupal_bootstrap_configuration(). If the file doesn't exist, display a message to the user instead of redirecting.

Pseudo code:

  // Redirect the user to the installation script if Drupal has not been
  // installed yet (i.e., if no $databases array has been defined in the
  // settings.php file) and we are not already installing.
  if (empty($GLOBALS['databases']) && !drupal_installation_attempted()) {
    include_once DRUPAL_ROOT . '/core/includes/install.inc';
    if (file_exists(DRUPAL_ROOT . '/core/install.php')) {
      install_goto('core/install.php');
    }
    else {
      // Display an error message to the user letting them know they need to
      // copy install.php to their server.
    }
  }
miguel’s picture

miguel CreditAttribution: miguel commented

As far I know it is a common use to remove install.php [1]. So all these people are also affected.
[1] http://drupal.org/upgrade/finished

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Pasqualle’s picture

Pasqualle
Location 🇭🇺 Budapest
CreditAttribution: Pasqualle as a volunteer commented
Issue summary: View changes

It was recommended with SA-CORE-2012-003 that the install.php could be deleted.
see Notes section on https://heine.familiedeelstra.com/drupal-7-installer-vulnerability

So yes, Drupal should work correctly without the install.php file.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev
quietone’s picture

quietone CreditAttribution: quietone at PreviousNext commented
Issue summary: View changes
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Bug Smash Initiative

#12 suggests that this is no longer a problem.

Can anyone reproduce this problem?

Since we need to confirm the problem still exists before continuing, I am setting the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Pasqualle’s picture

Pasqualle
Location 🇭🇺 Budapest
CreditAttribution: Pasqualle as a volunteer commented

I should have wrote it better, I wanted to say that the bug should be fixed, as it was recommended to delete the install.php file.

From the codebase it seems the bug is still present in Drupal 7.
https://git.drupalcode.org/project/drupal/-/blob/7.x/includes/bootstrap....

And it seems D9 is also redirecting without checking if the file exists.
https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/lib/Drupal/C...

But as I am unaware of any recommendation to delete core/install.php in D9, it could be a feature request for D10.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone CreditAttribution: quietone at PreviousNext commented
Version: 9.5.x-dev » 10.1.x-dev
Category: Bug report » Feature request
Issue summary: View changes

I have updated the Issue Summary and meta data based on the last two comments from @Pasqualle

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.