Rule #553 of the Internet: You know your app’s doing well when idiots make the effort to attack it for no apparent reason. For a while now, Textise has been suffering chronic perfomance problems and regular outages. You might have noticed. I certainly did!
First of all, my hosting company started complaining that Textise was hogging all the CPU on the shared server it was on. So they throttled it. This was understandable but reduced performance even further. It seemed that hundreds of thousands of requests were hitting the app every day, all sourced from the Opera browser. Obviously, this immediately looked suspicious, given that Opera isn’t the most popular browser on the planet, and none of these requests were showing up in Google Analytics (which was presumably assuming them to be bots).
So, I signed up for CloudFlare, a proxy service that can filter out malicious requests before they hit your app server. CloudFlare found threats, and stopped them, but it seemed to miss the Opera-sourced attacks, which didn’t reduce at all.
Plan B: I moved Textise from the shared server to a dedicated, physical box. This costs ten times more a year but at least allows me to see exactly what’s going on. The new server coped better with the traffic but still had to be throttled to stop it crashing out on a regular basis.
Plan C: I added code to the Textise app to reject calls from Opera. This did, finally, reduce CPU, but I was unhappy about such a blanket approach.
Plan D: I trawled through the server logs and, with the help of the R Project, I extracted page hit info from Google Analytics so I could compare the two. Eventually, I found another way to identify the malicious requests, meaning that genuine Opera users would still be able to use Textise, and coded it into the app. I talked to the folks at CloudFlare, in the hope that there was a way I could configure CloudFlare to do something similar, but it turned out that would cost me mucho cash, so the code stays in the application. This is a shame, as I’d rather these stupid calls were blocked well before they get anywhere near my server.
I’ve now also added SSL to the site. This doesn’t stop attacks, of course, but it means that your use of Textise is protected. A downside is the bookmarklet and Firefox add-on were slightly broken. I’ve now fixed the bookmarklet (to update, just drag it into your bookmark bar again) but, because Mozilla are changing the way that add-ons work again, I need to re-write the FF add-on, which will take a little while longer.
Any thoughts on perhaps providing a non-https version of textise?
I ask because a recent use case was brought up here:
https://groups.google.com/forum/#!topic/comp.sys.apple2/JiWYnLf22YA
An, admittedly small, contingent of Apple II users with working Ethernet cards and an 8-bit IP communications package called Contiki are using a text-based web browser and finding little is really available to them. I found textise.com, and thought it might be a very useful proxy site for them, but https isn’t something that can be feasibly done within the 8-bit environment. I’m sure that this would also be useful for other 8-bit platforms with similar hardware and enthusiasts.
Thanks!
LikeLike
Hi Rich,
Thanks for getting in touch.
I’ve given this some thought and concluded that making exceptions to allow HTTP would be difficult – and a lot of config work for a small number of users.
Sorry for the disappointing response. I hope you find a solution.
Ian
LikeLike
Doesn’t seem to work with this link:
https://www.quotev.com/story/7538364/Undertale-Songs/101
Gives me:
System.Web.Services.Protocols.SoapException: Server was unable to process request. —> System.ArgumentOutOfRangeException: Index and length must refer to a location within the string. Parameter name: length at System.String.Substring(Int32 startIndex, Int32 length)
LikeLike
Hi,
Really, really sorry – only just found your comment. Now, that is a slow response!
You’re absolutely right, that page refuses to convert. I’ll have a look.
Thanks for the feedback.
LikeLike
“smilar”->similar
LikeLike
Ha! Thank you – I’ll fix that 🙂
LikeLike
I wonder if the Ddos attacks are an effort by malware distributors to stop Textise from reducing assault by flash laced ads or maybe hired by clickbait web sites who blame Textise for less traffic.
As you surmise. A victim of your own success.
I use Textise for the Maddow blog on msnbc not just for ads but because of the absurd amount of scrolling to get past videos I don’t have time to watch and get to the text stories. Textise compresses their web site brutally and makes it useful. Without Textise I would not use it.
LikeLike
You may be right about the attacks but hard to prove, of course.
Pleased you’re finding Textise so useful 🙂
LikeLike