Put a site into maintenance-mode, but not for all...
Hi @all... i try to figure out how to put a live website into the maintenance-mode, but leave it fully accessible by a fixed IP-Range of developers so that bugs can be fixed and tested in a fully running site... Drupal V5.x... My way would be a modification of menu.inc: --snip-- function menu_execute_active_handler() { $client = $_SERVER['REMOTE_ADDR']; $arrAllowed = array ('www.xxx.yyy.zzz','127.0.0.1'); if (_menu_site_is_offline() && !in_array($client,$arrAllowed)) { return MENU_SITE_OFFLINE; } --/snip-- the array is just in there for testing purposes, will be replaced by a GLOBAL or something like that... Is this the only way to do it (as after an update menu.inc could be replaced...) ? Jens
Hi, I prefer whitelisting IPs in .htaccess via Apache setup, so that while you experiment, nobody will get to the site (PHP code) any way, but only those allowed. Gábor On Tue, Jan 6, 2009 at 2:25 PM, Jens Reinemuth <jens@reinemuth.info> wrote:
Hi @all...
i try to figure out how to put a live website into the maintenance-mode, but leave it fully accessible by a fixed IP-Range of developers so that bugs can be fixed and tested in a fully running site...
Drupal V5.x...
My way would be a modification of menu.inc:
--snip--
function menu_execute_active_handler() { $client = $_SERVER['REMOTE_ADDR']; $arrAllowed = array ('www.xxx.yyy.zzz','127.0.0.1'); if (_menu_site_is_offline() && !in_array($client,$arrAllowed)) { return MENU_SITE_OFFLINE; }
--/snip--
the array is just in there for testing purposes, will be replaced by a GLOBAL or something like that...
Is this the only way to do it (as after an update menu.inc could be replaced...) ?
Jens
� schrieb:
Hi,
I prefer whitelisting IPs in .htaccess via Apache setup, so that while you experiment, nobody will get to the site (PHP code) any way, but only those allowed.
G�bor
Nice idea, but we have a really nice "site in maintanance mode"-page that surely should be displayed instead of blocking all external users... This should not be experiments, but a really urgent bugfixing that should not happen to often (hopefully)... Next problem is, that you have to edit .htaccess, while the other way you simply have to login drupal and put the site in the maintenance mode, or back to live mode. Jens
On Tue, Jan 6, 2009 at 6:25 AM, Jens Reinemuth <jens@reinemuth.info> wrote:
Hi @all...
i try to figure out how to put a live website into the maintenance-mode, but leave it fully accessible by a fixed IP-Range of developers so that bugs can be fixed and tested in a fully running site...
I've thought about this problem as well and created the Maintenance Helper module: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/maintenance_hel... It leaves the site accessible, but prevents users from logging in unless they have a specific permission. It could probably be modified to take an IP range as an admin setting to determine who gets to login as well. I guess I should make a project page for it so it gets an issue queue and we can discuss these kinds of things ;) The concept was discussed http://groups.drupal.org/node/10582 prior to building it which has some good ideas on the field. Regards, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
Greg Knaddison schrieb:
On Tue, Jan 6, 2009 at 6:25 AM, Jens Reinemuth <jens@reinemuth.info> wrote:
Hi @all...
i try to figure out how to put a live website into the maintenance-mode, but leave it fully accessible by a fixed IP-Range of developers so that bugs can be fixed and tested in a fully running site...
I've thought about this problem as well and created the Maintenance Helper module:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/maintenance_hel...
It leaves the site accessible, but prevents users from logging in unless they have a specific permission. It could probably be modified to take an IP range as an admin setting to determine who gets to login as well.
I guess I should make a project page for it so it gets an issue queue and we can discuss these kinds of things ;) The concept was discussed http://groups.drupal.org/node/10582 prior to building it which has some good ideas on the field.
Regards, Greg
That's a perfect starting point... Lets make a project page and do it ;-)
On 6-Jan-09, at 9:23 AM, Greg Knaddison wrote:
On Tue, Jan 6, 2009 at 6:25 AM, Jens Reinemuth <jens@reinemuth.info> wrote:
Hi @all...
i try to figure out how to put a live website into the maintenance- mode, but leave it fully accessible by a fixed IP-Range of developers so that bugs can be fixed and tested in a fully running site...
I've thought about this problem as well and created the Maintenance Helper module:
That's a neat idea. Project page for sure! I could see it being useful for doing site updates. On many sites, the DB is mostly read-only unless you're logged in. I wonder if, especially for sites with the aggressive cache option set, if during maintenance all pages would be served from the page cache, so that the site never loads inconsistent data during an update.php run. Only if the page wasn't cached would a maintenance message appear. Another solution is the secure_site module. I use it on development sites as my IP changes to much to be useful in an .htaccess. Also, many corporate clients are stuck behind a proxy, making it harder to whitelist IP's. You could probably theme the secure site login page to be more friendly to the general public. --Andrew
Andrew Berry schrieb:
On 6-Jan-09, at 9:23 AM, Greg Knaddison wrote:
On Tue, Jan 6, 2009 at 6:25 AM, Jens Reinemuth <jens@reinemuth.info> wrote:
Hi @all...
i try to figure out how to put a live website into the maintenance- mode, but leave it fully accessible by a fixed IP-Range of developers so that bugs can be fixed and tested in a fully running site...
I've thought about this problem as well and created the Maintenance Helper module:
That's a neat idea. Project page for sure!
I could see it being useful for doing site updates. On many sites, the DB is mostly read-only unless you're logged in. I wonder if, especially for sites with the aggressive cache option set, if during maintenance all pages would be served from the page cache, so that the site never loads inconsistent data during an update.php run. Only if the page wasn't cached would a maintenance message appear.
Another solution is the secure_site module. I use it on development sites as my IP changes to much to be useful in an .htaccess. Also, many corporate clients are stuck behind a proxy, making it harder to whitelist IP's. You could probably theme the secure site login page to be more friendly to the general public.
--Andrew Ok...
The IPs are not the problem, as all Developers come via one Proxy-IP to the webserver... So do the testers, project-managers, ... Our customer is also routed via a proxy, so there should be 2 IPs to whitelist (perhaps some more for the externals...) which should be possible to be set via admin. The htaccess method is not possible as it prevents those ugly pop ups and that the page i have to realize this is also presented to mobilephone users and absolute dummies... so if you give them login-pages and they get access denied, they will check their logins over and over, but if you give them an "error-page" they will simply blame us... Jens
On Tue, Jan 6, 2009 at 7:36 AM, Andrew Berry <andrewberry@sentex.net> wrote:
That's a neat idea. Project page for sure!
Great - done http://drupal.org/project/maintenance_helper The first release is created, but not yet published (it is waiting for the packaging script). Regards, Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
Greg Knaddison schrieb:
On Tue, Jan 6, 2009 at 7:36 AM, Andrew Berry <andrewberry@sentex.net> wrote:
That's a neat idea. Project page for sure!
Great - done http://drupal.org/project/maintenance_helper
The first release is created, but not yet published (it is waiting for the packaging script).
Regards, Greg
Thanks... i'll check it out asap and have a look over it, how to include the needed patches... I thought perhaps it should not be IP-specific, as for example we locally also have the cases where customers enter the site via mobilephones and you have to identify them via some header variables... So it would be better to write some abstract functions that compare allowed and not allowed access tries depending on some rules that are not only IP-based... Have some other projects richt now, will check it out tomorrow. Regards, Jens
participants (4)
-
Andrew Berry -
Greg Knaddison -
Gábor Hojtsy -
Jens Reinemuth