Add support for maintenance mode bypass via maintenance.ip file

[rjocoleman]

Description

OpenMage/Magento 1 has a Maintenance Mode (503 error) invoked by placing a maintenance.flag in the application root.
This does not allow any visitors to bypass. The app is not run at all, no setup scripts etc are invoked and the database is not accessed.

Sometimes developers need to get past maintenance mode while regular users shouldn't be able to.

This PR adds support for this via a maintenance.ip file (in the same format as Magento 2, in the application root (next to maintenance.flag).

To use the feature in this PR:

$ cd $MAGENTO_ROOT
$ touch maintenance.flag # maintenance mode is now on
$ echo '123.456.789.321' > maintenance.ip # 123.456.789.321 is now allowed past maintenance mode
$ echo '123.456.789.321,127.0.0.1' > maintenance.ip # replace the content of maintenance.flag, both 127.0.0.1 and 123.456.789.321 are allow past i.e. multiple IP addresses are comma separated
$ rm maintenance.flag # disable maintenance mode, the ip whitelist remains for next time
$ rm maintenance.ip # or, remove the ip whitelist

Questions or comments

There are a number of ways to implement this. This PR is a starting point and I am happy to modify.

How it currently works:

• the maintenance.flag check has been moved further down index.php to below the mage.php require (nothing is run at this point)
• if maintenance.flag is detected but no maintenance.ip the usual maintenance mode files are included and processing is interrupted.
• if maintenance.ip is also detected Mage::init($mageRunCode, $mageRunType) is run (where $mageRunCode and $mageRunType are set with unchanged logic/ENV).
• Mage::init() initialises Mage but does not render the application, it does not run setup scripts, it is used to give access to helper code and xml config.
• This is to use Mage::helper('core/http')->getRemoteAddr() to collect the connecting IP address, getRemoteAddr() uses the system of remote_addr_headers in local XML config for example when behind a load balancer or CDN these should be set for the real client IP to be used in various places through Magento. (e.g. X-FORWARDED-FOR, CF-CONNECTING-IP or X-REAL-IP

The advantage of this approach it's very similar to Magento 2 and the IP address is consistent with the rest of the Magento application. The downside is the call to Mage::init() for everyone that hits index.php while this is enabled. I am unsure if this has any undesirable outcome in a maintenance situation (however setup scripts are not run).
This will work even if the database is down, the regular users will still get 503.

Alternative approach 2:

• Don't move maintenance.flag check down index.php.
• Don't call Mage::init().
• Use $_SERVER['REMOTE_ADDR'] environment variable.

The advantage of this approach is it remains closer to the existing behaviour. The disadvantage is the case users have a load balancer, CDN etc that obscures the real client IP this must be set at the web server level or REMOTE_ADDR won't work as expected e.g. Nginx ngx_http_realip_module or Apache mod_remoteip
This is pretty much the same as current with an IP check, it also doesn't care if the database is down.

Alternative approach 3:

• Move maintenance.flag check down index.php
• Hit the database to get Mage::getStoreConfig('dev/restrict/allow_ips');

This doesn't match Magento 2 but is the Magento 1 place for developer IPs. The database needs to be up, I don't think this is great approach.

Feedback welcome, I've been using this approach for some time via a composer patch and haven't yet encountered anything that's put me off!

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All automated tests passed successfully (all builds are green)

[kkrieger85]

Approved.

It would be nice to add some information about this feature in README

[github-actions]

Unit Test Results

1 files  ±0  1 suites  ±0   0s ⏱️ ±0s
0 tests ±0  0 ✔️ ±0  0 💤 ±0  0 ❌ ±0 
6 runs  +4  4 ✔️ +2  2 💤 +2  0 ❌ ±0 

Results for commit 1d82190. ± Comparison against base commit 2310733.

[Hanmac]

This PR breaks DB Updates when using maintenance mode + ip file to bypass it

[Hanmac]

@rjocoleman you should do this after the bypass flag is checked:

$config = Mage::app()->getConfig();
$config->getCache()->remove($config->getCacheId());

this explicit removes the cached config, and forces Mage::run to load the config again and check for DB Updates
but only when maintenance + bypass flag is used.

[rjocoleman]

@Hanmac I'm sure the project will happily take a PR to improve it if there is a reproducible bug. I am out of the magento / ecommerce world and don't have capacity to look at it sorry.

[addison74]

@Hanmac - Please open an issue, I will make time to test your report. If it is confirm we can go further and evaluate the optimal solution in a PR.

[addison74]

@Hanmac - Do not forget to supply all information to reproduce the issue.