Cidram: Remove captcha cookie warning

[Dibbyo456]

To the access denied page cidram output this while using Invisible Captcha:

<p class="detected">For most users, the page should refresh and restore normal access. In some cases, you may be required to complete a CAPTCHA challenge.<br />Note: CIDRAM uses a cookie to remember when users complete the CAPTCHA. By completing the CAPTCHA, you give your consent for a cookie to be created and stored by your browser.<br /></p>

I would like to have it removed from the output.
Basically I'm trying to create a access denied page with no trace of "cidram", so the visitors won't know which firewall i'm using.

[Maikuolan]

So, as some general background to anyone wondering why CIDRAM displays a cookie warning in the first place: This is primarily to ensure that CIDRAM complies with EU cookie legislation (per noted by the supplementary to the documentation for the __api__ configuration directive). Compliance with that legislation generally shouldn't be a problem at all for any websites that aren't based in the EU and aren't targeting EU traffic, but could be quite important for any websites based in the EU or targeting EU traffic.

From a technical perspective, the particular output cited above can be divided into three parts.

1. Information specific to the particular reCAPTCHA API being used (V2 or invisible).

When the "invisible" API is used: "For most users, the page should refresh and restore normal access. In some cases, you may be required to complete a CAPTCHA challenge."

When the "V2" API is used: "In order to regain access to this page, please complete the CAPTCHA supplied below and press the submit button."

1. The cookie warning.

(The "Note: CIDRAM uses a cookie to remember when users complete the CAPTCHA. By completing the CAPTCHA, you give your consent for a cookie to be created and stored by your browser." part).

1. The paragraph wrapper.

(Per the cited output, like: <p class="detected">{{Part 1}}<br />{{Part 2}}<br /></p>). In the default template file, the <div id="detected">{ReasonMessage}</div> part of template file is where it all gets parsed (alongside all other information pertinent to the block event to be displayed to the end-user).

The relevant L10N strings are:

• recaptcha_cookie_warning
• recaptcha_message
• recaptcha_message_invisible

The part of the codebase responsible for triggering the cookie warning can be isolated down to a single line of code, located in vault/recaptcha.php:

        $CIDRAM['reCAPTCHA']['GenerateContainer'](true);

In the absence of any specific configuration directive (as is the case at this time), to get rid of the warning, simply omitting the true from that line of code should do the trick. Alternatively, modifying the relevant L10N strings should do the trick, too. However.. due to the nature of how updates work, any changes to the core codebase like that, would be overwritten the next time that there are any updates available that affect the changed files in question. So, having a specific configuration directive would generally be better.

I'll see what I can do.

[Dibbyo456]

However.. due to the nature of how updates work, any changes to the core codebase like that, would be overwritten the next time that there are any updates

This is exactly what I was afraid of. Right now I'm using a CSS patch to hide it but anyone lookup the source code. Thank you for looking into it.

[ghost]

Compliance with that legislation generally shouldn't be a problem at all for any websites that aren't based in the EU and aren't targeting EU traffic, but could be quite important for any websites based in the EU or targeting EU traffic.
Contrary it is, EU legalisation targets any site that has visitors from the EU. Why do you think the US has started to block EU visitors on their sites?

Also worth nothing, even though the cookie technically falls under the "necessary for function" clause, good practice is to not set it before the visitor has given consent to cookies ;)

[Maikuolan]

Latest commit provides a new configuration directive, show_cookie_warning, allowing users to control whether the cookies warning should be displayed or omitted. :-)

Before I do anything else, just to confirm: Did we want to provide a way to omit the API-specific information (e.g., the "For most users..." part) as well? Or should just omitting the cookie warning ("Note: CIDRAM uses a...") be sufficient?

[Dibbyo456]

Did we want to provide a way to omit the API-specific information (e.g., the "For most users..." part) as well?

I believe, this would be nice as well. To a permanently blocked IP this is pretty much useless.
A additional option would be nice IMO :)

[Maikuolan]

Sorry for the delay. I had noticed the bump this morning, before going to work, and had been planning on pushing some more commits towards finishing this off when I got home, and replying here afterwards with some details about it, but I'm feeling pretty exhausted and it's getting late now. Not working tomorrow though, so I'll push the new commits and reply in the morning.

[Maikuolan]

..and done. :-)

It should now be possible to disable the API-specific messages displayed when a reCAPTCHA instance is presented to end-users via the newly added show_api_message configuration directive.

The changes implemented, overall, aren't particularly significant, but the reason it has taken me as long as it has to get around to implementing these changes: I actually originally had a slightly different idea about how I was going to go about doing this (an idea a little more complicated), and had been planning to try to implement support for different kinds of CAPTCHA systems at the same time while at it (e.g., HCaptcha, probably something homebrew, and whatever else I might find which seems popular enough to be worthwhile adding support for), but I kept finding potential complications about going about it that way, which could've potentially led to new bugs, new problems, etc.. plus backwards-compatibility concerns.

I'm still thinking I'll try to implement support for different kinds of CAPTCHA systems at some point in the future, but backwards-compatibility considered plus potential complications, I'm thinking I'll earmark it as a major change, as something to postpone until v3 (and as something separate to the particular issue at hand of course, too).

Anyway, with that done, I'll go ahead and mark this issue as implemented and close it.