Protected/Development/Maintenance Mode

[adrian]

Just now, horst said:

I think, sending a 503 and "retry after" should be done everytime if the whole site is closed / protected, regardless if you call it protect mode or maintenance mode. This is important for SEO.

I think both of the modules, yours and Petes, should do that by default, when the whole site is not accessible for SearchEngines. (just my 2cents)

 

I'd like to hear more on your thoughts about this, because I was just finalizing incorporating your changes and I was about to add a protected vs maintenance option, because I know that many people use this module to protect a site that is always protected (it is only ever for logged in users), so I am not sure in this case that Retry-After is appropriate, because it will always be inaccessible. I don't really think 503 sounds appropriate either. If you have a site that is protected from public view then you don't care about SEO anyways

Is there something obvious I am missing?

[horst]

On a site that is always protected, it simply doesn't matter.

But on a site, where I regularly only use some single protected pages but a big part is publicly accessible, there it is better to use SEO friendly headers when closing the whole site. It is important for sites that are already indexed, and temporarily are not accessible. That's why you thought it belongs to Petes module. But when I already have installed ProtectMode and it can close down the whole site, I have maintenance mode already, or not?

Maybe best solution would be to offer both methods for the root page? Radio or something else for: protect | maintenance, plus a datetime via showIf for maintenance?

[adrian]

6 minutes ago, horst said:

Maybe best solution would be to offer both methods for the root page? Radio or something else for: protect | maintenance, plus a datetime via showIf for maintenance?

Yeah, that's essentially what I have done.

Any thoughts/experience with this:

Quote

You have to be careful with Retry-After header if you send the same timestamp to a lot of unique clients. Imagine it's 15:30 and you send Retry-After: Thu, 10 Feb 2015 15:40:00 GMT to everyone around - just because you somehow estimated that service will be up at 15:40. The longer you keep sending the same timestamp, the bigger DDoS "attack" you can expect from clients respecting Retry-After. Basically everyone will schedule retry precisely at 15:40 (obviously clocks are not perfectly aligned and network latency varies, but still), flooding your system with requests. If your system is properly designed, you might survive it. However chances are you will mitigate this "attack" by sending another fixed Retry-After header, essentially re-scheduling attack later.

That being said avoid fixed, absolute timestamps sent to multiple unique clients. Even if you know precisely when your system will become available, spread Retry-Aftervalues along some time period. Actually you should gradually let in more and more clients, so experiment with different probability distributions.

http://www.nurkiewicz.com/2015/02/retry-after-http-header-in-practice.html

What clients do you think they are referring to? I would have thought that search bots might be triggered by this, but doubt they would all hit it immediately at the Retry-After time. As for manual users - that is unlikely also. I guess I could randomize the Retry-After time somewhat - maybe at 1 minute intervals for up to 10 minutes after the entered time, but it sounds like overkill for almost all sites. I'll ignore unless you have any strong thoughts on it.

[adrian]

Ok, I have committed the new version.  A huge thanks to @horst for contributing this functionality.

 Here are the key new sections to the module config:

@Christophe - just pinging you to make sure you see this new functionality.

[horst]

Many thanks @adrian,

now I'm back again in regular update process with the module. Yep!

---------------------

18 minutes ago, adrian said:

What clients do you think they are referring to? I would have thought that search bots might be triggered by this, but doubt they would all hit it immediately at the Retry-After time. As for manual users - that is unlikely also. I guess I could randomize the Retry-After time somewhat - maybe at 1 minute intervals for up to 10 minutes after the entered time, but it sounds like overkill for almost all sites. I'll ignore unless you have any strong thoughts on it.

I think only search bots will act according to retry-after.

I have read on Googles advices on how they like to see handled maintenance mode for already indexed sites. And it was a 503 with a "retry-after" .

If the estimated timestamp is passed, I added 60 minutes to the current time and sends this. Maybe, you can add this to the explanation, that one can check "send retry-after" but without a fixed timestamp too? This way we have enough possibilities, I think.

[adrian]

5 hours ago, horst said:

Maybe, you can add this to the explanation, that one can check "send retry-after" but without a fixed timestamp too?

I guess what you are saying here is if you set the "Estimated End of Maintenance" to a very short time from now, then the Retry-After timestamp will be changing constantly as soon as that initial timestamp point is reached. Is that what you mean but "without a fixed timestamp"? I see that the Retry-After actually allows specifying a timestamp or a delay in seconds, but a constantly changing timestamp would essentially be the same as the "seconds delayed" approach?

[Christophe]

Thanks a lot, @adrian and @horst. You guys are awesome. As is this community.

[horst]

4 hours ago, adrian said:

I guess what you are saying here is if you set the "Estimated End of Maintenance" to a very short time from now, then the Retry-After timestamp will be changing constantly as soon as that initial timestamp point is reached. Is that what you mean but "without a fixed timestamp"? I see that the Retry-After actually allows specifying a timestamp or a delay in seconds, but a constantly changing timestamp would essentially be the same as the "seconds delayed" approach?

Yes, thats exactly what I mean. If one specify a fixed timestamp and this point is passed, I have added a delay to the current time and passed that back. As you said, this is the same as the delayed approach, but with little overhead. This can be simplyfied: send header with fix timestamp if it is in the future, otherwise send header with delay in seconds. Maybe, the delay should be configurable too?

[Juergen]

Thanks @adrian for this module. It would be great if it supports multilanguage depending on the browser language. F.e. if the browser fits one of the installed languages then show the message in this language, otherwise show the default language.

[adrian]

7 hours ago, Juergen said:

Thanks @adrian for this module. It would be great if it supports multilanguage depending on the browser language. F.e. if the browser fits one of the installed languages then show the message in this language, otherwise show the default language.

Of course that would be a good idea! I am going to be away for the next two weeks, but I'll add it to my list to do when I get back.

Thanks for the suggestion!

[adrian]

On 10/17/2016 at 9:57 PM, Juergen said:

Thanks @adrian for this module. It would be great if it supports multilanguage depending on the browser language. F.e. if the browser fits one of the installed languages then show the message in this language, otherwise show the default language.

Done!

Please let me know if you have any problems and also be sure to "Like" @Can's post over here: https://processwire.com/talk/topic/5825-multi-language-support-for-module-config-fields/?do=findComment&comment=131595 because he showed me how to add ML module config settings.

[Juergen]

Wow ! Thanks adrian. Exactly what I mean. I will try it and if there are problems I will post it here.

[Juergen]

Hello adrian,

does this module check for the browser language? I always get the German text. I have changed my browser settings to English and German but no changes on the frontend. English and German are the installed languages in my PW.

Best regards

[adrian]

1 minute ago, Juergen said:

does this module check for the browser language?

Firstly, I am still not completely au fait with all the elements of multi-language, so happy for feedback on this.

Currently it doesn't check the browser language - it checks the user language, so if you send a person a link to something like: mysite.com/en/ then you should see the english version of the message - I am assuming your default language is not english in this example, but you get the idea.

Do you think there needs to be improvements here? I haven't done much reading/experience on this, but I though that automatic language detection was not recommended, but please correct me if I am wrong and let me know the best way to do that and I'll incorporate.

[adrian]

@Juergen - what about installing @Pierre-Luc's AutoDetect language switcher module: http://modules.processwire.com/modules/autodetect-language/

If that is set up to redirect to the /en/ version of the page, then the translated version of the login message etc should be displayed.

[Juergen]

Thats a good idea. I will try it.

[adrian]

Thanks to a request from @Rudy this module now supports "Allowed Roles". This is basically the same as the option in the Page Protector module, but I thought it might be nice here as well. It allows you to limit access when in Protected Mode to a defined list of roles. 

[SwimToWin]

@adrian - Very nice module! I was requested to add password / passphrase protection of a Danish site, and this module came very handy.

Background image added:

html {
	background:url('/images/background.jpg') no-repeat center center;
	min-height: 100%;
	background-size: cover;
}
body {
	min-height: 100%;
}

Transparent background color added on top of the background photo (so the text remain readable):

legend {
	background: #eee;
	opacity: 0.7;
	color: #333;
	font-weight: bold; 
	font-size: larger;
}

If you have time to spare, then I have two minor enhancement requests:

1. The TITLE tag prepends "protected :: " before the site title.
Better: Make the prepended string translateable (perhaps that's already possible somehow?).
Or, add multi-language capabilities as suggested by Juergen (I would prefer a text string tough).

2. Login with a single passphrase field
I only need one field (password / passphrase) - but the module require that I add two fields (username and password).
Better: Allow the administrator to specify a passphrase ... if the passphrase is correct then a default username and password is activated. Here is how it may work:

* Administrator creates a guest user.
* Administrator creates a passphrase and links it to the guest user.
* When end-user logs in with correct passphrase, then user is logged in as the guest user.

[bartelsmedia]

Thank you for this useful module.

Please allow a minor hint: By glorious GDPR, website owners must provide a privacy policy information.

This requirement may include a login page! It's absurd, I know, but even when visiting the login page, personal data (the IP address *sigh*)  is stored in the log file. Judges defined this as collecting personal data, web site owners have to inform about.

Just to let you know, so a sensitive client is not put at "risk".

[adrian]

@bartelsmedia - thanks for the heads up. I think you can achieve your needs quite easily via the "Login Template" option. Hope that helps.

@SwimToWin  - sorry I let your post go by un-noticed. I am afraid I don't really have the need (and hence the time) to add a single passphrase option, but I am certainly open to a PR if you're willing.

A tad OT, but I think PW needs to start fostering a culture of providing PRs more often than requests for features (both in 3rd party modules and in the core). This is absolutely not directed at you personally - I just feel like we need more contributors across the board because there are too few people being spread way too thin.

[bartelsmedia]

Thanks. Done that. Thanks again for this very useful module.

[sww]

Hello,

strange behavior. This modul worked fine since activated 10 days ago. But all of sudden it stopped working. User can see the page even not logged in. Nothing has changed since.
Is there a cache-something-issue or anything else that might cause the problem?

Best,
Stefan

[adrian]

Hi @sww - I really don't know what the issue might be. I would need to start debugging the steps in the module to see where / why it's not showing the login form. Can you try to investigate? If not, if you PM me login details for the site, I'd be happy to take a look.

[Pete]

Hi Adrian, it's been a while since I needed this functionality and didn't realise I'd left my own module still up - I'll likely take it down soon and direct people to yours if you think that makes sense?

I'm going to use yours for a project, but can I suggest an option to hide the login form? For normal maintenance I wouldn't let any roles log in and as superuser I'd just go to the right URL instead is my thinking.

It may also be worth changing the title of your module in the directory to "Protected/Development/Maintenance Mode" so those keywords are found during search as currently only mine comes up for "maintenance".

[adrian]

Hey @Pete - I've added an option to remove the frontend login form.

Hope that works for you.

Let me know if you have any questions or suggestions!