problem posts

Recaptcha and prototype.js conflict

One of Cogneato’s clients noticed that Recaptcha wasn’t working on their site. The checkbox wouldn’t check at all. I noticed that there was an error like “Unexpected token in JSON at position 0” in the browser’s console log. Since this was one of our really old sites, I figured it might have some sort of inadequate polyfill for JSON.parse(). I saw that the site was using Prototype.js, so I looked through the script to see if it was overriding that method, but it wasn’t. That did put me on the right track, though, to find the Stackoverflow answer that solved it for me.

Prototype was overriding the now browser standard reduce() method of Array.prototype with its own, incompatible functionality. The solution was simply to remove that method from the “prototype.js” file. We weren’t using the special Prototype functionality anywhere, so this didn’t cause a problem. If we were, we’d probably have to duck punch the browser’s functionality to handle both method signatures.


Fallback webfont and emoji

Recently I found that browsers will download a fallback webfont (@font-face) to try to find an emoji or other missing character. I was looking at the perf characteristics of my site when I noticed that the browser was downloading a webfont that wasn’t being used at all. After some digging, I found that the browser was going down through the full font stack to try to find an emoji I had added to that page, downloading the webfont on the way.

This is probably not a common setup, but I have a webfont in my font stack down stack from some similar common system fonts, as a fallback just in case. It uses a nice system font unless it can’t find it, in which case it uses the webfont, unless it can’t use that, in which case it uses a less desirable system font or the generic font class.

Continue reading post "Fallback webfont and emoji"

Fighting form spam

Cogneato has dozens of sites with openly submittable forms on them, and they have no doubt all had some level of problems with spam submissions. Bots, and perhaps people, like to share their links or services, try to hack sites, or whatever other nefarious or annoying purposes they may have through forms, which require some sort of server side processing, and will possibly result in human processing as well, such as with sent emails, database data, or comments on a website.

Spammers have gotten more sophisticated over time, and over the last year or two, have really started to hit Cogneato’s sites hard and get past the protections we had in place. We’ve had to add protections on forms that didn’t have them before, and use more techniques to attempt to detect spam. We’ve recently added a set of checks of the submitted form data and the submitter IP address that produces a score of “spaminess” that we can then use to block the submission if the score is above a threshold. That score script is the primary purpose of this post, but I will cover the other techniques we use as well.

Continue reading post "Fighting form spam"

PHP-FPM / Apache caching symlinks

At Cogneato, we use symlinks to point the web server to different versions of our software for websites. Sometimes, especially on our Ubuntu server, which uses PHP-FPM to serve PHP files through Apache, I was noticing problems caused by scripts being loaded from the previous symlink destination when I changed to the new one. There seems to be some sort of caching going on. The solution was to restart PHP-FPM and Apache after switching the symlinks. On Ubuntu, this looks like:

ln -s /path/to/new-version /path/to/software-link \
&& sudo service php7.2-fpm restart \
&& sudo service apache2 graceful

where the 7.2 is the version of PHP being used. Haven’t noticed the problem since.