I’m aware of the built-in security of the server, which forces the appending of the “i” parameter to the URL (e.g., ?i=1, ?i=2, ?i=3) on the first time the site is loaded.
Problem: It is forcing the appending of the “i” parameter to the URL again (the site does not load the first time, but I am removing parameters with JavaScript—no reloading), causing two redirects (first with the original URL, then with the parameter). This happens when the site (or tab) is inactive for some time (around ~3-4 minutes).
Example: I open a tab and type {website_url} for the first time in the browser. It redirects to {website_url}?i=1, which is okay (server security; it creates the cookie “_test”). Now I open another tab and do some work for about ~3-5 minutes. When I return and reload the website, it then redirects to {website_url}?i=2 (the “i” parameter value has changed).
Effect: When an AJAX request is made, it redirects to the requested URL with the “i” parameter, so it fails to get a response (not always, but as mentioned, it happens after being inactive for about ~3-5 minutes).
I hope this helps provide the context of the problem. If not, please let me know, and I can provide more information if needed.
The expiry of the “_test” cookie is about one year, so why is it forcing the “i” parameter in the URL again and again? Actually, I have no problem with the parameter, but it causes the AJAX request to automatically redirect to the URL because it has to append the “i” parameter.
Can someone suggest a possible trick or solution to handle the redirect of the AJAX request?
I love this hosting service, so I don’t want to leave it because of this problem. That’s why I am asking here personally in the forum.
The cookies have a very long lifetime set, but on the server side, the variables get rotated regularly so a hacker can’t just grab a cookie once and use it basically forever.
I don’t know how often the keys get rotated, but I can’t imagine it’s as little as 5 minutes because, as you observed, it makes doing anything with AJAX very difficult.
Scenario: I’m using a PHP script to download static files from my website in a ZIP file (~1-3GB). To manage this, I’m breaking the ZIP file into 10MB chunks for download.
Question: Is this approach acceptable? What effects might this have on INODE USAGE, HITS USAGE TODAY, Daily Hits Usage, Daily CPU Usage, Daily Entry Process Failures, Daily I/O Usage, and Daily RAM Usage? Could this potentially lead to my website or account being blocked or suspended?
I run this script only once every few weeks or months as a backup, and it is used solely by me—no other users.
What is your site’s URL? If you have a custom domain, you may want to consider using Cloudflare.
Using backup scripts in general isn’t advised, as they use a lot of server resources- especially if they have to break a file that large into multiple pieces (compressing all of those files into a single zip takes quite a few resources on its own). A better option is to simply use Filezilla to download all of your site’s files. This won’t use any of your account’s daily resources, is far more stable, and won’t count toward your account’s storage limitation.
Hitting the daily limits usually just leads to the offending hosting account being temporarily suspended for a day. That happening repeatedly can lead to the account being permanently deactivated, however.
Thank you for the suggestion; I’ll go ahead and use it.
I’m unable to share my site’s URL due to privacy reasons, as it contains personal information. I’m on a free tier plan, and my domain ends with .000.pe.
Very well. You’re using a free subdomain though which means you can’t use Cloudflare, and unfortunately that’s the only way to do what you want, except for upgrading to premium.
It breaks any way to build any kind of single page application that needs to talk to a PHP backend, so saying it’s bad UX is quite an understatement.
This shouldn’t be the case, and I can try to test on my end to see if this is indeed how our servers work with the cookie values being very short lived.
But before I do that, could you please verify some things to make sure it’s actually a server issue and not something else? Please verify that:
The domain and protocol you’re using are the same. Cookies are set on a per-domain basis, and most browsers will not send cookies that were created over HTTPS to a HTTP page.
There are no weird browser settings or extensions that could perhaps result in the cookie getting destroyed early.
A good way to test for all of this is to open the Developer Tools in your browser, refresh the page and check that the __test cookie is sent with the initial request. Then wait for the AJAX request, and verify that the AJAX request which breaks also has the same cookie set with the right value.
So a script running somewhere other than our hosting is creating a backup of your website? Conceptually that should be fine, but I do wonder where the ZIP files fit into this. Creating large zip files on our hosting is not OK, and especially not good for your account’s IO usage.
I must say your forum support is fantastic—fast, helpful responses, and active admin make it feel like a premium service. I plan to support you by purchasing your premium service soon. Thanks for providing such a great free hosting!
I’m sending AJAX requests from my website file to another file on the same domain using HTTPS, specifying just the file name in the URL (without the protocol). I’m not using .htaccess to enforce HTTPS.
I’ve tested this in almost every browser, including Chrome Incognito, and the issue persists.
The request is being sent to the correct AJAX URL (including protocol and cookies).
It would be very helpful if you could provide the correct way to send an AJAX request to the PHP file, specific to my situation.
The issue was resolved. I’m now using FileZilla to back up my entire data folder, which is better than downloading a zip file.
AJAX should work like you would expect. If you send a request to the same domain, it should reuse your existing cookie and it should just let you in without requiring the browser challenge again. If it does generate a browser challenge, it’s very hard to solve that I think.
That’s why my answer is short and unhelpful. You’re looking for a solution which I don’t think exists.
One possible option might be to have some code to detect this is happening and refresh the page if it does. But those kinds of workarounds should not be necessary.
Sorry for the delay, I didn’t have time to investigate the issue until today.
I tested the issue with a little script that pings a PHP script in the background every minute.
The first time I was able to reproduce what you saw: after about 5 minutes, the requests were failing. But then I refreshed the page, and it keep working for about 1.5 hours until the issue happened again.
So this tells me that the parameters are rotated once every few hours. And the fact that it broke after 3-5 minutes sounds more like unfortunate coincidence than normal behavior.
While I recognize the problems that this causes, it’s hard to fix this without building a completely new challenge system. I’m going to keep this under consideration, but don’t expect any changes in the near future.
So the best I can do right now is to suggest a workaround. Which could be to build some logic into your AJAX code to detect when you get the Javascript challenge response from the server (the Content-Type of the response being text/html is quite telling), and if you see it, refresh the page.
