@williammorgan said:
i know
> this parameter is for protection from bots . when a non browser thing acessed a webpage it usualy never execute recived javascript and never send cookies.so bot never get contents of webpage.
i lost my one day playing around this.
i tried some other hosting because of this.i know that peoples asked to remove it many times since beggining…
but your answer is “NO its for security "
if we said " we dont need security " admin says " we need it "
main point is " its not for security its just to make customers forcefully upgrade to premiuim”
because admin said " premium accounts have no such security "
so what i have to say honestly is
always iam thankfull for provided free service but that is not subject here.
" please remove such useless security . its just a crap and ugly idea"
because
this secret is now public.and any bot makers can bypass this by storing cookies and executing javascript in their softwear.
so then what is the point of this .
You’re right, if someone wants to do a targeted attack on a website hosted here, they can easily circumvent the security system. You could run your attack in a (headless) browser or just reverse engineer the code and access the website anyways.
However, the vast majority of attackers never go through this trouble. They just crawl thousands or millions of websites looking for outdated software, unsafe plugins and other points of entry they can attack. If they don’t find anything (because the website only responds with 403 Forbidden responses), they move on to the next target, and leave your website alone.
With premium hosting, we can do without this security system. With premium hosting, we can actually take the time to investigate hacking attempts and work with the customer to resolve any vulnerabilities in a way that works for them. That’s the kind of personal attention you get with premium hosting.
On free hosting, that kind of personal attention would be way too costly. A free hosting account makes us hardly any money, so we can’t afford to spend extra server power on taking the hit of attackers and then fixing individual free hosting users’ websites. That is why we have to resort to more aggressive and mandatory security systems to keep hackers out.
Why don’t we make it configurable? Because most people don’t understand the necessity of security until they get hacked. They want to be able to use their WordPress app so they disable the security system. Soon afterwards we get abuse reports saying that website is being used to share phishing URLs, because the website owner neglected to implement proper protection for their comments system.
We’d like to be able to trust our users to know for themselves what’s necessary to keep their website secure. But time and time again has shown that people frequently disable all those pesky security systems and then come to us whenever their websites eventually get hacked.
@williammorgan said:
not only that
it affects and breaks many features. it breaks both client side code and serverside code .
it ruined everything you gave freely.
for example
1. i made http redirects to another page in my site but it failed because of this.
2. i used javascript ajax in client side to get part of my pages but it always returns error
3 .if i used site analysis softwear it never works.
HTTP redirects to other websites work without any problem. I don’t know what kind of Javascript trickery you used for your redirect, but I can confirm that both PHP redirects, HTML meta refreshes and basic JS window.location redirects work fine.
AJAX requests also are fully supported. Just make sure to use the same URL as the one you’re visiting. If you are visiting www.example.com, you can do AJAX requests to other URLs on www.example.com. AJAX requests to other domains won’t work (like example.com or api.example.com), because the security system breaks CORS. But within the same website, there’s nothing stopping you.
If you don’t agree with me here, please share more information about the issues (e.g. example URLs, code snippets) so I can actually try to help you.
@williammorgan said:
perfect solution
transperantly handling problems are best way instead these kind of half cooked dirty meal.
here we can use
* only enable defence against suspicious blacklisted ip
* intrusion detection by url acess/ per time
* allow acess to requests from same site endpoints
* allow acess to user who used it once in past.
Point 3 and 4 is exactly what the current security system does. Whenever you access a domain name hosted by us for the first time, a cookie will be placed in your browser to identify you as a user who can access that website. As long as that cookie is present in your request, you can access the website (point 4). With that access, you can load HTML pages, load static assets, perform AJAX request and do whatever else you could expect on a website (point 3).
Again, if you need any help figuring out why the AJAX and redirects don’t work on your website, please bring specific details so we can help you.
Point 1 and 2 are interesting. Effectively, that’s what Cloudflare is doing. However, as someone who has been using Cloudflare for 8 years now (started using them approx. half a year after Cloudflare launched), I can testify that IP based and request based intrusion detection is not accurate enough. I’ve still seen plenty of hacking attacks going straight through Cloudflare, while simultaneously blocking plenty of legitimate requests.
The heuristics to determine whether a request or IP address is dangerous or not is extremely complicated and never more than an educated guess. And if even Cloudflare (who handle 7.5% of all websites) can’t get it perfect, what chance do we have?
We provide a website hosting service. Our current security setup lets you host websites. It won’t let you host file sharing services, CDN services, database hosting services and so on, because that’s not the service we provide. Our current setup protects websites in a clear and predictable way, and it doesn’t lock out random people.