On my website, hosted by InfinityFree, I have a simple HTML web form, with a “submit” button to post the results back to the same page for writing to the MySQL database. Upon posting, the viewer then gets a screen confirming the post as I am testing for $_POST upon reload of the page. All very simple stuff that worked fine on my previous hosts, and I’ve used countless times elsewhere.
Here, it works for about 99% of visitors without issue. However, a few of my visitors have reported that they press the button, and simply get the form appearing again (which means a “POST” was not detected).
I’ve been capturing $_SYSTEM variables upon page load, and can see that when this happens (the form being loaded again with nothing posted) $_SERVER[‘REQUEST_METHOD’] = ‘GET’ not ‘POST’ and the URL has a “&i=1” after it.
Usually in these cases, the IP address of the visitor has changed slightly as well, often they are using a VPN which seems to dynamically change the IP address during a browsing session (usually just the fourth set of digits). IP address changes wouldn’t normally be a problem.
My theory is that, for those view visitors that have their IP address change during a browsing session, the InfinityFree security system is assuming that the session posting the form is different from the one that originally loaded the form, which results in the addition of the ?i=1 to the URL, and then the POST request gets changed to a GET request, which prevents the posting of the form data to the receiving page and therefore the database.
Meanwhile, people like me who have a constant IP address unless I reboot my router, have no issues whatsoever.
Is my diagnosis correct of what I am experiencing, and is there any way to get around this?
We often have a case on the forum when post becomes get
due to redirect to https or vice versa from https to http
and then the browser makes an extra hop to retrieve the page which results in GET instead of POST
I don’t know if your users have VPN or a browser that forces HTTPS in the settings or something like that.
I would have to mock something up as this form I’m speaking of is a voting form which is only open for specific periods of time, so please bear with me while I do that. Also as mentioned, 99% of people don’t seem to have an issue so it would require trying to mimic their situation.
My first guess is that the cookie from the browser security challenge has expired, or the challenge values were rotated. If so, the security cookie is missing or invalid, so the POST request will go to the security challenge page, which generates a new cookie and sends people back to the form. Unfortunately, because of that redirect, the POST data is lost, and the request becomes a GET request instead.
I don’t know how often the challenge values are rotated, but the effect you’re seeing should be extremely rare. Of course, if people kept the page open for a long time, the chance of this happening becomes a lot more likely.
Enabling a VPN nuking their cookies could be an explanation, but I’ve never seen anything like that, so it seems unlikely.
Thanks for your answer.
To give a bit more context - the voting form in question is only open for about 20 minutes, and the people who are experiencing this issue typically get it multiple times and the time between loading the form and submitting it is as little as 1 minute and rarely more than 10 minutes.
Are you saying that the security cookie becomes invalid if the IP address changes? I know that in most cases (but not all) cookies are retained, because I am setting a cookie upon loading the form which is still present, valid and with the same value when submitting, even if their IP address changes.
I’ve just replicated the issue with my mobile phone.
I opened the voting form, entered my response, then turned off my phone’s wifi (causing it to connect to the mobile network) then submitted my response. The voting form loaded again.
It seems that the IP address changing requires a new browser security challenge.
I can put a simple form together at some point in the next couple of days so you can test this, but surely this would be the same on everyone’s accounts so you could test this yourself if you have an HTML form on your site?
To solve the issue fundamentally, you can code your submission mechanism as AJAX. Although the terms does not allow for external API hosting here, using API for your own website in the same session is acceptable.
For each submission, simply emit a POST as AJAX to your submission endpoint using JSON, check if you can get a ‘ok’ (or any custom response that you set for your code). If you cannot get that, simply trigger a new window to popup and automatically get past the challenge, then automatically try again.
The way to achieve it is to have a page that automatically closes itself, which was called upon a failed AJAX POST. Since the page is opened by your JavaScript, your code is still running after the popup getting closed, and then you can try POSTing again.
Normal behavior is to only clear cookies if they expire, not on IP changes. But I could imagine that if you have a browser extension that links to your VPN, then enabling the VPN drops all cookies to prevent websites from tracking you. I have no idea if such a thing exists, but I wouldn’t be surprised if it did.
And we don’t link the cookies to IP addresses on our end. Even if you are on a network connection which basically assigns you to a different IP for every request, you should have no problem accessing your website.
Does this actually solve the issue? To do the AJAX request, you also have to include the security cookie. This happens by default, so using AJAX work in normal circumstances. But so do form submissions. And I cannot think of any reason why AJAX would work but a regular form submission would not, as they pass through the same security checks.
Hi there, please forget I mentioned VPN servers, I’ve now determined they’re not relevant.
I am connected to the internet solely by my home fibre provider, I have no VPN, no extensions or anything else non-standard. As I mentioned, yesterday I changed my IP address after loading the HTML form by disconnecting from wifi so my phone was then connected to the mobile network. Posting the form resulted in a GET and reloading the form.
So I maintain that the IP address change does seem to be causing the ?i=1 to be appended to the URL. When I get time I’ll make a form and provide the URL so you can test it.
Thanks for your message but I’m afraid you’ve totally lost me. I know PHP, SQL and Javascript but I’ve never encountered AJAX. I guess what you’re suggesting is attempting to check if the IP has changed before posting?
<html>
<head>Voting Form Test</head>
<body>
<?php
if(isset($_POST['sendVotes'])) {
?>
<p>Thanks for submitting the form</p>
<p><a href="form.php">Back to form</a></p>
<?php
}
else {
?>
<form action="form.php" method="POST">
<p><input type=submit name="sendVotes" value="Click to submit form"></p>
</form>
<?php
}
?>
</body>
</html>
Quite simply, I load this form, click the button and I then see the message “Thanks for submitting the form”.
If I repeat this but change my IP address between loading the form and submitting, I always get ?i=1 after the URL afterwards, and the form reloads. As mentioned before, I’m doing this by switching between home Wifi and mobile data. I have no VPN or anything else. Please test this yourselves.
Thank you! Just to reiterate that the constant here is not so much the VPN, as the change of IP address. I don’t have a VPN but I get the same result with changing the IP.
What I meant is that if the code posts form content using AJAX, the code has the opportunity to check if it got the expected results (for example an exact match “OK”) before considering it complete. If it cannot get this result, the script can simply window.open a new popup that gets redirected to the security challenge, which automatically sets a new cookie or whatever on that same browser, and then when the window gets automatically closed when finally reached the popup’s destination, an window closed event is triggered and the script can retry. At this point the browser already has the cookie set and the AJAX will have that cookie as well.
Do you agree that the behaviour shown by the simple HTML form I’ve created show that the security challenge happens every time the IP address is changed and not otherwise?
Please can you advise if this can be fixed?
Interesting, the same thing doesn’t happen for me. I’m using OpenVPN on Linux though, not Windows.
I know the cookies aren’t bound to IPs.
Interesting. Does the IP address changing also log you out of all sites?
Also, I’m curious what exactly happens under the hood. With the request-that-should-be-post-but-becomes-get after changing the IP, does the browser still send the old cookie along with the request (which the server then rejects) or is the cookie missing entirely? The Network tab in the developer tools should provide the means to extract this data.
This is a very strange issue. I cannot reproduce it and I cannot explain it, but this definitely should not be happening.
No, changing the IP address doesn’t log me out of anything.
I am setting my own cookie for visitors of my website - it’s a very long term cookie, so I can detect repeat visitors. If their IP address changes that cookie is still set and the value still retained. But I’ve observed Windows clients, Android phones and Apple phones changing IP address which causes the ?i=1 to be added to the URL, which, if that happens before a POST, causes a GET instead because of the redirect.
Are you saying that if you visit that URL I provided with a phone, and change your IP address, and click the button, that you don’t get the form again? Oxy demonstrated it perfectly.
The issue isn’t with cookies, it’s whatever mechanism causes the security redirect. I guess it can’t only be testing the absence of the cookie it creates.
So just to emphasise again, this is nothing to do with VPN, and in fact nothing to do with POST/GET. The issue is - if the IP address changes, the browser redirects for the security challenge. Every single time.
Check this image. I am creating my own log files for site activity. This person has recently been viewing my website, his IP address keeps changing slightly (it’s a T-Mobile IP Address in the USA, maybe he’s a passenger in a car so keeps connecting to different cells). The second column is the cookie that I am maintaining, note how that is constant. But you can see, every time his device makes a request from a new IP address, you get a ?i=1 on the URL.
This seems to be happening, yes. When the IP changes and a new request to the site is made (either POST or GET, like a refresh), the server appears to reject it, as a new request to the aes.js file is made, and the __test cookie gets overwritten with the new value, which is then accepted by the server.
