Getting unexpected 403s from the hosting?

Hey there, I tried to make a custom redirect to a discord invite from a page. I tried to do it via a simple 301 redirect rule in htaccess, adding it before Wordpress block there. I have since cleaned up my efforts and purged cache, but I still get 301 whenever I try to get to https://quaysideriviera.ca/chat Any idea why? I managed to make a redirect on https://quaysideriviera.ca/speak using an extension (I think the extension does it either via php or JS, but not htaccess) but I would prefer to do that to /chat and whatever I do, /chat always returns a 403

Feels like the ban taking effect, not of scripts but because of the address.

Few words from admin:

Yes, other same meaning words is the way to go.

That creates more questions than it answers really:

1. What’s so special about live chats that they’re banned?
2. Are they banned on premium plans too?
3. Is it possible to have an exception for the /chat endpoint if I only use it for an external redirect?
4. Does it apply to the domain names too? so like if I made a chat. subdomain, would it be blocked too? I mean, blocking all /chat endpoints seems so silly to me I don’t know where to expect it to end.
5. Does it mean I can’t make an article that looks like https://domain.com/how-to-set-up-a-chat ? That’s just silly.
6. Would webchat bridges to IRC or Discord be blocked too?

7. Any other random words that the hosting just bans like that that I should be aware of?

Ok, I bypassed that by deploying a redirection via CF, so it fires even before it hits the hosting. But I still would love to know why. It’s very bizarre.

If you are in a live chat with another person, then your browser somehow needs to know when the other person has sent a new message. There are various ways to do that.

Websockets are the best way to do that, but websockets from PHP is difficult at best, and requires some special server setup that you won’t find with a web hosting service.

So the only alternative is polling. Which means: constantly refresh the page in the background to check if new messages have been posted. This means that every second or so, the browser needs to make a request to the server, which then needs to fire up a PHP script, which needs to open a database connection, and check the messages table for new messages. And it needs to do that again, and again, every second, for every active visitor.

This is extremely inefficient, and puts substantial stress on the servers. It generates so much load that even simply relying on the account limits was not enough.

Banning the “chat” word entirely in URLs is a very blunt instrument to combat live chat scripts, but it was necessary.

Live chat scripts are banned on premium plans too for the same reasons I described above. But the block on the “chat” keyword is not there.

We don’t do special requests. Our hosting is intended to work in a certain way, and it will work that same way for everyone.

I don’t think it’s banned for domains, but feel free to try.

That’s correct, on both counts. But that’s how it works.

If the chat messages pass through our servers (which they would probably need to), then yes. Again, for all the reasons I listed above, just replace “database” with “Discord API”.

I hope you’ll never encounter any other block, but there are a few more blocked keywords:

Just know that we don’t block “random” words. We block very specific words for very specific reasons. We are fully aware of the side effects they will have on legitimate websites, and we don’t make decision to block keywords like this lightly.

I see. Very interesting. I’ve never encountered websockets or polling blocked. I guess other hostings I tinkered with make virtual environments for each client, where they strictly limit the amount of memory or CPU PHP can access, so no further limiting is required.

But then, livechat is not the only case where frequent polling/websockets are used? I could host some web-game where people play with each other. That would be as intensive as a chat for sure if I route them all through backend rather than p2p. Or I could just poorly implement a piece of functionality that would end up poking PHP all the time. I totally expect some poorly made plugins to maybe make that mistake.

I guess webchats is the vast majority of usecases for intensive polling. But is there no better solution for this? Something that would calculate the average backend hits per client IP per hosted property and raise alarm when that average is too high, then it can be addressed individually. And then maybe it would be easier to find offending engines, scripts or plugins and ban them separately or in conjunction with the url. So like the /chat url is only banned if your use phpbb or whatever else engine uses that endpoint.

Presumably that you are talking about the CloudLinux LVE, free hosting have that exact system asaik, except that when you hit a limit you get straight up suspended, not throttled.

Yes, which is why those examples you mentioned will also get you suspended.

Ultimately these are about two special limits on the free hosting: browser limit and hits limit.

Free hosting sends a JavaScript challenge before first load and verify the cookies afterwards, meaning a request could take more computing power than normal.

There’s also a hit limit. That’s what’s actually doing the jobs as banning accounts whose website makes excessive requests to the server, not the “chat” keyword as what you may have imagined. Other cases don’t have a keyword banned because it’s generally hard to find a common keyword unlike “chat”.

I see, and that makes sense. It’s just if the hosting already bans accounts with excessive hit usage, why not allow chat in the url. It’s just a very crude blocker that seem to be doing more harm than good. Idk, maybe if the hosting detects a chat in the url, then send an email warning that the usage of livechats is banned and the account may be suspended if there’s a livechat hosted there? There are plenty of client-only chat bridges that rely on existing chat infrastructures hence don’t need anything from backend. Renaming endpoint from chat to talk or whatever is just so awkward.

gosh imagine some user generated content website. Like a simple forum. And it has permalinks properly generated. And now whenever anyone posts any topic with ‘chat’ in the title, it’s suddenly a 403. What a nightmare.

Nevermind, it’s fine if it’s just on free hosting. Not a biggie. Nobody can expect to host anything serious on a free hosting anyhow, so it’s ok.

It’s a little disheartening but it requires just one tiny step over this roadblock. For ASCII-only keyboards, synonyms are the easiest and make most sense, “talk”, “call” or “text” all fit 4 characters.

If you are making the links yourself on your pages, and really wanted the word “chat“ without the trigger, you can use a unicode like U+FF41.

screen-chａt01564×192 5.47 KB

screen-chａt02228×659 9.13 KB

Or maybe if the URL is from a user-generated content, you have to set a custom filter to capture it turning it into “c-h-a-t”, “ch4t“, ”chａt” or something before publishing.

If the chat is hosted outside (so nothing does through the free hosting servers as you described) then it’s probably loaded through the outside as well.
As a clarification, this “chat” keyword ban will not and cannot happen on 3-rd party resources. If you use an external chat and load the chat script from somewhere else, it will just work.

I’m not a staff, but every block I’ve seen here have a reason behind them. Free hosting are abused way more than you might have imagined…

We do actually use something like that under the hood. But we have a rather unique setup where we allow more resource burst instead of having strict limits.

Still, as I said before, this was not enough to combat the issue of live chat scripts hammering the server.

That’s exactly it.

The ban on the chat keyword is a blunt instrument. It doesn’t block all bad cases and doesn’t permit all good cases.

That’s more or less what happens on premium hosting. Instead of sweeping bans up front, it’s more based on system monitoring and investigation of individual bad cases.

But for free hosting, that’s just not feasible. The number of free websites is very large, and the revenue per user is extremely small. So manually checking individual websites for potential abuse is something we would like to avoid doing as much as possible, because the effort required to do that is simply unsustainable for free hosting.

That’s also not practical. Not only do we have to somehow know and have rules for every chat script in existence, it also means that for every incoming request, you first have to somehow analyze what website is behind the URL (which can be very tricky with complex .htaccess rules). That’s a quite complex process that is too slow and server intensive to practically run for every request. A simple keyword ban, on the other hand, is very efficient.

Checking software during installation is more practical than doing it at runtime. But then you run into the problem that some software contains live chat functionality which the website owner can just choose not to use.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.