Email Obfuscation (EMO)

[Klenkes]

@Roope Nice module! This is an standard install on all the websites I control.

Lately I had to insert al lot of MSTeams chat links on school websites, that look like this:

https://teams.microsoft.com/l/meetup-join/19:cf8e53b5711b487@thread.tacv2/123456789012342540?context=%7b%22Tid%22%3a%22e957100c-9b8a-4b7f-b945-fbxx-xxxx-xxxx...

Due to the @ in the link EMO tries to encode it, which of course fails.

For now I excluded the page with those links in EMO settings.

[neophron]

Hi there,

I have two PW installations on the same hosting company (Ionos ? ). Till two or three weeks ago everything's worked fine. Now both websites show almost the same errors:

Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
161


Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
163


Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
164


Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
171


Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
171


Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
171


Deprecated
: Array and string offset access syntax with curly braces is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module
on line
171


Warning
: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php
on line
238


Warning
: session_name(): Cannot change session name when headers already sent in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php
on line
242


Warning
: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php
on line
248


Warning
: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php
on line
249


Warning
: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php
on line
250


Warning
: ini_set(): Headers already sent. You cannot change the session module's ini settings at this time in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php
on line
251


Warning
: Cannot modify header information - headers already sent by (output started at /homepages/39/d334050941/htdocs/processwire_06.07.18/site/modules/EmailObfuscation/EmailObfuscation.module:161) in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/modules/Process/ProcessPageView.module
on line
142


Deprecated
: Function get_magic_quotes_gpc() is deprecated in
/homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php
on line
81

I called the »support« and asked them, what they exactly changed, but they couldn't help me. I have to wait till Monday.

PHP is 7.4, PW is 3.0.165 and the EmailObfuscation modules is the latest version. The bad thing is, hat the backend is not accessible. Is there a way to deactivate a module via ftp? 

[netcarver]

I think you should be able to move the offending module directory/file out of the site/modules folder into a temporary directory. That might restore your site's operation enough to go into the admin interface where you can clean things up if you need to.

[neophron]

@netcarver Thanks.

I renamed the module directory like this: _EmailObfuscation

Now, I'm getting these errors / messages:

Deprecated
: Function get_magic_quotes_gpc() is deprecated in
/wire/core/WireInputData.php
on line
81

Notice: Trying to access array offset on value of type int in /wire/core/PagesLoader.php on line 138

I can log in the backend, but I'm getting a blank page with a lot of errors.

Deprecated: Function get_magic_quotes_gpc() is deprecated in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php on line 81

Warning: Cannot modify header information - headers already sent by (output started at /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php:81) in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/admin.php on line 27

Deprecated: Function get_magic_quotes_gpc() is deprecated in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php on line 81

Warning: session_regenerate_id(): Cannot regenerate session id - headers already sent in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php on line 787

Warning: Cannot modify header information - headers already sent by (output started at /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php:81) in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php on line 799

Warning: Cannot modify header information - headers already sent by (output started at /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php:81) in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php on line 1036

Warning: Cannot modify header information - headers already sent by (output started at /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/WireInputData.php:81) in /homepages/39/d334050941/htdocs/processwire_06.07.18/wire/core/Session.php on line 1037

 

[horst]

2 hours ago, neophron said:

The bad thing is, hat the backend is not accessible. Is there a way to deactivate a module via ftp?

You can precede every desired module directory with a dot (.) to make it ignored by PWs module parsing.

Example: site/modules/WiremailSmtp/ is picked up by PW, site/modules/.WiremailSmtp/ is ignored.

[ngrmm]

On 10/5/2016 at 3:19 PM, Bacelo said:

Actually I can't unistall the module "TemplateEngineFactory" as the template relies on this
I'll continue having a deeper look into and try to cut it down.

@Bacelo did you find any solution back then?

 @Roope I'm using PW 3.0.200 and it looks like the module is stuck somewhere in the process.
Script is not added automatically. When I add it manually it does not find anything in the document.
So with script added manually and using $sanitizer->emo($string) it find the email and replace it completly with a noscript tag.

 

[thausmann]

The module isn't working for me aswell. I did some debugging and the issue seems to be having a <header> element in the HTML anywhere before an email address.

This issue was mentioned earlier and allegedly fixed, but the problem I'm facing is gone when changing my <header> to a <div>.

This obfuscate method should probably skip replacing addresses in the <head>, but cannot distinguish it from <header>. 
Adding a negative lookahead to the <head regex seems to fixes this issue. Here is a Git diff that's working for me. [Pull Request]

Edit: just a conceptional thought, to support obfuscation everywhere, I could imagine a regex matching any email address in the entire HTML, and collect obfuscated attributes in a custom attribute, something like data-emo="title,value,innerHTML".

[Robin S]

Hi @Roope,

There seems to be a problem when the text for an email link contains the smart apostrophe character: ’

It causes part of the closing <a> tag to get duplicated and this appears as visible text in the browser.

Source code in CKEditor:

After Email Obfuscation has processed it:

 

[chuckymendoza]

Hi @Roope

I get the following error message by using a server with PHP 8.1 on all pages, that DO NOT include an email:

Deprecated: is_nan(): Passing null to parameter #1 ($num) of type float is deprecated in
... FileCompiler/site/modules/EmailObfuscation/EmailObfuscation.module on line 248

When I switch back to PHP 8.0 (or lower), everything seems to be fine.
(ProcessWire 3.0.200, EMailObfuscation 1.2.5)

-Thomas

[patman]

On 10/27/2022 at 2:14 PM, chuckymendoza said:

 get the following error message by using a server with PHP 8.1 on all pages, that DO NOT include an email:

Deprecated: is_nan(): Passing null to parameter #1 ($num) of type float is deprecated in
... FileCompiler/site/modules/EmailObfuscation/EmailObfuscation.module on line 248

@chuckymendoza try commenting out line 247 and 248:

/**
 * is_nan(NULL) is deprecated in PHP 8.1 and $key[64] is not initialized
if(is_nan($c2)) { $e3 = $e4 = 64; var_dump($c2);}
else if(is_nan($c3)) {$e4 = 64; var_dump($c3);} 
*/

worked for me without an issue and I do not see the purpose of the code.

[patman]

Hi!

I ran into the issue that for longer pages the module did not work. After a lot of research I figured out that this is an issue with the regex and can be (fixed) using:

	/**
	 * obfuscate email addresses at given (html) string
	 *
	 */
	private function obfuscate($html)
	{
  	ini_set('pcre.backtrack_limit',1250000); // FIXME! required for long documents

on line 315. As one can read from https://stackoverflow.com/questions/4180910/php-preg-match-all-fails-on-long-strings, in general using regex for parsing HTML documents is a bad idea (as I understood). To me this therefore sounds like the module needs some rework to do the parsing in a different way in order to avoid memory issues. Did someone already do so? Otherwise I would work on it and do a PR.

[chuckymendoza]

On 10/31/2022 at 6:40 PM, patman said:

on line 315. As one can read from https://stackoverflow.com/questions/4180910/php-preg-match-all-fails-on-long-strings, in general using regex for parsing HTML documents is a bad idea (as I understood). To me this therefore sounds like the module needs some rework to do the parsing in a different way in order to avoid memory issues. Did someone already do so? Otherwise I would work on it and do a PR.

This would be wonderful to get new, working module @patman
I think, others will get the same problems if they switch to PHP8.1 sooner or later. It seems, please correct me if I'm wrong, that the module is no longer maintained. I don't know, how others solve the problem with spambots crawling for emails, but I really would appreciate, if someone could update the module, or create a new one? 🙂 
Thanks so much, also, for the tips on solving the errors.
Thomas

[Roope]

Hi all!

Just dropped in to say that this module is not abandoned. I’ve been super busy with my paying projects and also in personal life at the moment so I haven’t found time to fix current issues.

If @patman or someone else is willing to push PRs or even to make full rewrite I’m happy to pull them in. Current issues are easy to fix tho but unfortunately my time is VERY limited for the rest of the year. 

[patman]

Hi @Roope, thanks for letting us know! I'm fixing some issues and would provide PRs as soon as I have found a working solution. Spoiler: the regex way of looking for addresses runs into a memory/performance issues on pages containing a lot of code.

[patman]

I fixed the PHP 8 issues and also the problem mentioned in my previous post. See my pull request https://github.com/BlowbackDesign/EmailObfuscation/pull/15 for a solution.
If someone has the opportunity please test and report back if there are issues. Actually, it should be a drop-in replacement. @Roope please consider my PR after testing.

 

[update AG]

Two issues to your useful module «EmailObfuscation»:

1. In PHP >= 8.1 a deprecated message is thrown for lines 247/248: is_nan() cannot handle NULL values

2. If a mailto link contains an "apostrophe" (’) in an RTE field (e.g. in <a href="mailto:events@saq.ch">d’annulations écrites</a>), the EMO javascript produces a strange character (see screenshots).

Regards, Markus

[gebeer]

On 2/7/2023 at 1:42 AM, patman said:

I fixed the PHP 8 issues and also the problem mentioned in my previous post. See my pull request https://github.com/BlowbackDesign/EmailObfuscation/pull/15 for a solution.
If someone has the opportunity please test and report back if there are issues. Actually, it should be a drop-in replacement. @Roope please consider my PR after testing.

 

I just tried your fork and the replacement is not working for me. The preg_match_all inside the parseNode method doesn't pick up email addresses at all. I dumped $node->nodeValue and even if valid email addresses are in there, they don't get detected by preg_match_all and matches[0] always is an empty array.

Also, if email adresses are wrapped inside an a tag with href="mailto:..." they don't even appear in $node->nodeValue and therefore do not get parsed.

[patman]

@update AG Thanks for the feedback, I'll have a look at that specific issues.

<update>I just noticed I fixed at least the first issue, but I needed to cancel the PR as I have another issue</update>

@gebeer I found out that modifying the DOM while iterating over it has issues. So it might not catch some of the relevant addresses. I'll need to modify the method again. 😞 Is it possible that you provide me the HTML source of the document you tried to use with the module for testing?

[gebeer]

9 hours ago, patman said:

I found out that modifying the DOM while iterating over it has issues. So it might not catch some of the relevant addresses. I'll need to modify the method again. 😞 Is it possible that you provide me the HTML source of the document you tried to use with the module for testing?

I did some testing with HTML like

<p>E-Mail: <a href="mailto:test@email.com">test@email.com</a></p>

and it didn't catch the links. 

I think this is related to https://github.com/patman15/EmailObfuscation/blob/cfb7d7e50cf7ac47a6b40b054e4174275df7b68e/EmailObfuscation.module#L375 !empty($arr = ...) The $arr definition should be outside !empty(), I guess.

Also you original mailto_pattern didn't catch the address until I removed self::fastpattern.

Also mailto hrefs like this do not work:

<a class="icon social ma" href="mailto:?subject==?UTF-8?B?RGllIFdlYnNpdGUgZGVyIFNQSUVMQkVSR0VSIE3DvGhsZSB3dXJkZSBkaXIgZW1wZm9obGVu?=&amp;body=https%3A%2F%2Fspielberger.ddev.site%2Fde%2Fimpressum%2F" title="Diese Seite per Email teilen"><span class="sr-only">Diese Seite per Email teilen</span></a>

And yes, I think modifying the DOM while iterating can cause some issues. You might want to collect all relevant node instances in an array first and then iterate over that and do the replacement.