iFN having a half-thought out detector to prevent that does sound vaguely familiar. Just can’t remember if it’s to stop it because it works, or if it’s to stop it to prevent the user from digging their own grave.
6 Likes
If that were the case, and the JavaScript code didn’t cause any hit issues as you mentioned previously (which I never experienced in the 2+ years of having that in my code), why would iFastNet want to block it? As far as I understand, it doesn’t tamper with the security system; it’s merely a cosmetic change. It wouldn’t make sense to prevent users from changing how the URL bar looks.
This would make sense to have. However, I implemented that code on my website years ago and never once had that problem.
That is strange; I never had that happen to me. Are you sure that nothing else caused your .htaccess to revert back to default?
7 Likes
I’m certain. I put it on a testing site I have and didn’t touch anything untill checking today
5 Likes
Curious to know what happens if you put the code back on the same site again.
6 Likes
Stupid way
Pretty sure you could recreate this without params with nearly the same amount of code
Atleast let us make our own security system, then submit it for review or something, if it’s good enough it can stay instead of this “?i=” system.
This hosting site is the best I’ve ever seen (99% better than all I encountered of)
Just why.
Unless it’s required by Ifastnet, I suggest you replace this. I agree with @super_user_123 and @yanageorge .
By the way, if you make plans that ARE NOT CONTROLLED BY IFASTNET, even if it doesn’t affect hosting that much, I would buy it
You are right, so yep don’t get your hopes up.
4 Likes
It’s harder than it looks. But if you have any specific ideas on how to achieve this, I’d like to hear them.
Please keep in mind that the reason this parameter is added is for the cases where the browser does execute Javascript but doesn’t store or send the cookie. Just leaving out the parameter would result in the security check being hit continuously, which triggers an endless loop. The parameter is designed to break that endless loop.
Any system to replace it would need another way to track state. Tracking state across requests is usually done with cookies, but cookies not working is the only reason why this system is needed.
This browser validation system is also just the most visible part of a suite of security checks we run. There are also less visible parts, including IP rate limiting and user agent detection to block bad traffic.
The problem is that it cannot realistically be good enough.
Our system is very lightweight and blocks attack traffic with minimal server load, long before hitting your website code. Anything you could build into your own website runs after the request already reached it, so it can’t match that.
Also, basically any time when someone says “I want a different security system”, what they actually mean is “I want a less intrusive security system”, but “less intrusive” also means “less effective”.
And good to keep in mind: protecting your website against attacks doesn’t just benefit you, it benefits everyone. A website being attacked generates excessive server load, which hurts performance and availability for other websites on the server too. So we cannot just let you weaken the security of your own website.
That’s also setting aside a whole category of practical issues. A custom system would require us to design standards for it to conform to, contribute engineering effort to review the code, potentially implement and support integration points, and then monitor on an ongoing basis whether the system stays effective and isn’t weakened after the fact. That’s a lot of ongoing effort to maintain essentially tailored security for individual sites, which is unsustainable for any low-cost hosting service, let alone a free one.
So no, per-site custom security isn’t going to happen. There is going to be one solution, applied system wide for all websites. What that shared system actually looks like is something we can debate.
It is setup by iFastNet, so I cannot “just” replace it. But the people at iFastNet are reasonable, and are willing to consider good ideas.
iFastNet’s premium plans are genuinely good, and don’t have this system. Any plan I could offer either keeps the core hosting the same, just with a few extra features, or means building a completely parallel platform to iFastNet’s premium plans, which would just be redundant. Either way, there is not going to be anything that’s substantially different from anything available today.
5 Likes
Yeah, you were talking about offering plans that only added a few extra features, if you can make that I would buy it
Offering a small plan with additional features is in the back of my mind, but the tailored security is not going to be a part of it. There are a lot of problems with the whole idea of account specific security, as I already explained in detail in my previous post.
If you actually want to get full control over how your website is secured, you’d need your own server where you can decide the setup yourself. A VPS can be had for a pretty low price, but then you’re responsible for managing it, which takes a lot of extra know-how. A middle ground is a Managed VPS, where you get your own server but the provider manages it on your behalf, but those typically cost at least $100 per month, and quickly go up to many times that price.
A key aspect of web hosting is that the hosting provider is responsible for managing the hosting server so you don’t need to worry about that. Part of that is that the hosting provider decides how to ensure optimal security and performance of the hosting. The kind of custom security that you want is inherently not part of web hosting because the idea of web hosting is that security is the hosting provider’s problem.
So that’s why this won’t be part of any “extra features” plan. It’s not a matter of price. Customizable security simply isn’t something a shared hosting service can offer. Any service at these prices will be a commodity, because custom work is expensive.
But if all you want is to get rid of the current security system, there is a very obvious low-cost solution available already: just buy a premium plan at iFastNet. A Start Premium plan can be had for as little as $30 per year and ensures you don’t need to bother with this system at all anymore.
What you’re looking for is free hosting that doesn’t behave like free hosting. But I cannot give you that, because that’s what free hosting is: constrained, so we can keep costs low enough to be able to offer it for free. Making the hosting faster, more reliable and more versatile isn’t a feature that can just be added, it’s fundamentally distinct infrastructure.
I don’t understand why you’re happy to pay us but not iFastNet. Our free hosting is powered by them, and many decisions about how the hosting works were made by them. iFastNet isn’t some unknown third party, they’re the provider who has kept your website running this whole time. Their premium hosting is a separate platform, built to be faster and more capable, but it’s run by the same people you’ve already been relying on.
3 Likes
add a .htaccess file and put this in
# Turn on Rewrite Engine
RewriteEngine On
# Deny URLs Not Composed of “a-zA-Z0-9.+/-?=&” characters
RewriteCond %{REQUEST_URI} !^/(wp-login.php|wp-admin/|wp-content/plugins/|wp-includes/).* [NC]
RewriteCond %{THE_REQUEST} !^[A-Z]{3,9}\ [a-zA-Z0-9\.\+_/\-\?\=\&]+\ HTTP/ [NC]
RewriteRule .? - [F,NS,L]
# Force / Suffix
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)([^/])$ https://%{HTTP_HOST}/$1$2/ [L,R=301]
# Forward Documents to .php Internally
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^(.*?)/?$ $1.php [L]
# Force https:// Prefix
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>
# Remove www. Prefix
RewriteCond %{HTTP_HOST} ^www\.
RewriteCond %{HTTPS}s ^on(s)|off
RewriteCond http%1://%{HTTP_HOST} ^(https?://)(www\.)?(.+)$
RewriteRule ^ %1%3%{REQUEST_URI} [R=301,L]
# Remove .html Suffix
RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.html [NC]
RewriteRule ^ %1/ [R=301,L]
# Remove .php Suffix
RewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.php [NC]
RewriteRule ^ %1/ [R=301,L]
this is from
I’ve seen mixed results with this. Personally, when I’ve tried it, its not worked.
I’ve also tried other .htaccess options that have been deleted.
Good luck but bare in mind it may not work
1 Like
it does not work in WordPress or other softaculous installs, but it has worked for me