Social Media Links with FBCLID Parameter Causing 400 and 404 Errors with App Servers

Mindwatering Incorporated

Author: Tripp W Black

Created: 03/07/2020 at 12:05 AM


General Web Tips

There is a new tag being added to URLs visiting apps and web sites with: ?FBCLID=.
Links coming out of a social media platform and to our servers are more often containing a unique tracking code like:

Needless to say this is causing some issues and Error 400/404 Errors.

For generic Apache/PHP and NGINX/PHP sites, we stripped the tracking id parameter by adding the following Rewrite Directive in the .htaccess file:

RewriteCond %{QUERY_STRING} "fbclid=" [NC]
RewriteRule (.*) /$1? [R=301,L]

Note: Web administrators generally allow you to add this to a .htaccess file in your main /web or /www/html folder.

For WordPress web sites, we can do something similar to the following Rewrite Directive on the server:
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} "fbclid=" [NC]
RewriteRule (.*) /$1? [R=301,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Note: If the RewriteEngine is globally on, you may not need the first line.

For Domino, the default Internet Site --> Rules --> Redirection Rules didn't seem to readily be able to remove the ?fbclid= string.
See technotes swg21214276 and swg1LO57800.

Although it looked like a DSAPI filter could be created, this required more time and testing since we have both Linux and MS Windows installations of Domino that would need to be front-ended. Therefore, performing a workaround by simply updating the $$ReturnGeneralError in our web apps, became our course of action.

The quick fix, was to simply add something like to the HTMLHead of the $$ReturnGeneralError form:
tmpredirectcode:= @If(@Contains(Path_Info; "?fbclid="); @Left(Path_Info; "?fbclid"); tmpurlbase + HomeDb);
tmpredirectdelay:= @If(@Contains(Path_Info; "?fbclid="); "3"; "90");
tmpredirect:= "<meta http-equiv=\"refresh\" content=\"" + tmpredirectdelay + ";URL=" + tmpredirectcode + "\">";

As the users would see the error handler page flash before redirecting, even with 0 seconds, we also added a friendly message saying we were fixing the link and redirecting the users to their page. In addition, this workaround could also strip other apps sending URLs, or alternately, still keep them and add those parameters but put them legally after Open Form, eg. !OpenForm&paramid=

previous page