Closed Bug 1347921 Opened 8 years ago Closed 8 years ago

php _post sometimes blank

Categories

(Core :: Security: Process Sandboxing, defect)

Product:
Core
Component:
Security: Process Sandboxing
Version:
55 Branch
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1351358
Tracking Flags:
Tracking Status
firefox55 --- affected

People

(Reporter: jonathanbaron7, Assigned: gcp)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170314110401 Steps to reproduce: On a local linux computer (Fedora 25), open a file with PhP code with Firefox Nightly (55oa1, several versions - not sure when this started). I will attach two small test files that illustrate the problem: phptest.html (which is the file I open) and welcome.php (the file with the PhP code that doesn't fully work). (Attaching both does not seem possible, so here they are.) <html> <body> phptest.html <form action="welcome.php" method="post"> Name: <input type="text" name="name"><br> E-mail: <input type="text" name="email"><br> <input type="submit"> </form> </body> </html> welcome.php <html> <body> Welcome <?php echo $_POST["name"]; ?><br> Your email address is: <?php echo $_POST["email"]; ?> </body> </html> Actual results: The _post is apparently not read at all. (Several tests indicated that this was the problem. The problem is limited to files on my local machine. Everything works if the file is on a remote server. And it is new. I used to do this all the time. The problem does not exist in the relatively stable version of Firefox (apparently version 52) that comes with the Fedora RPM, and it does not exist in Google Chrome. Expected results: For the test case, the variables I input, my name and email address, should display. They don't, but the script otherwise runs.
phptest.html should look like this. Sorry <html> <body> <form action="welcome.php" method="post"> Name: <input type="text" name="name"><br> E-mail: <input type="text" name="email"><br> <input type="submit"> </form> </body> </html>
Last good revision: da986c9f1f723af1e0c44f4ccd4cddd5fb6084e8 First bad revision: d8e1f5cf0a70a53e8a5532809096a0a5bf729196 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da986c9f1f723af1e0c44f4ccd4cddd5fb6084e8&tochange=d8e1f5cf0a70a53e8a5532809096a0a5bf729196 Many bug are fixed in this range. But this issue seems to be related to Bug 1289718.
Has Regression Range: --- → yes
status-firefox55: --- → affected
Component: Untriaged → Security: Process Sandboxing
Depends on: 1289718
OS: Unspecified → Linux
Product: Firefox → Core
Hardware: Unspecified → x86_64
Assignee: nobody → gpascutto
Flags: needinfo?(gpascutto)
Potentially related to bug 1344465.
Flags: needinfo?(gpascutto)
I think this is probably a duplicate of bug 1351358. Jonathan - would you mind testing with the following pref set to true in about:config: browser.tabs.remote.allowLinkedWebInFileUriProcess For bug 1351358 I'm working on a making this pref more discerning about when it does allow http(s) in the file content process.
Flags: needinfo?(baron)
(In reply to Bob Owen (:bobowen) from comment #4) > I think this is probably a duplicate of bug 1351358. > > Jonathan - would you mind testing with the following pref set to true in > about:config: > > browser.tabs.remote.allowLinkedWebInFileUriProcess > > For bug 1351358 I'm working on a making this pref more discerning about when > it does allow http(s) in the file content process. This did not help. The test case still fails. Now using 55.0a1 (2017-04-19) (64-bit).
OK I misunderstood, having re-read your description the welcome.php file is local as well. It seems that you are expecting the php script to run within Firefox. That's server-side code, I was not aware that Firefox has ever supported running it. Abe - you've provided a regression range, so I assume you managed to get that php code running within a local file load. Was this on Fedora?
Flags: needinfo?(amasresha)
Yes, Fedora 25 64 bits. It is still reproducible in latest nightly. Here is the screen capture. https://testing-1.tinytake.com/sf/MTUzMTI0Nl81MzEzMjU5
Flags: needinfo?(amasresha)
(In reply to Abe - QA (:Abe_LV) from comment #7) > Yes, Fedora 25 64 bits. It is still reproducible in latest nightly. > Here is the screen capture. > https://testing-1.tinytake.com/sf/MTUzMTI0Nl81MzEzMjU5 So, the behaviour is definitely different there, where we're prompting for an external application to open the php, but that's not the bug as reported. Jonathan - did you previously have some sort of local php server that was selected to automatically process the file as an external app? gcp - could that behaviour have been changed by the Linux sandbox?
Flags: needinfo?(gpascutto)
I think this bug is fixed with the new setting. I cannot fully reconstruct what happened. But here is the best I can do. The code in my original post did indeed fail in the way I said, and now I cannot figure out why, because my computer will not run ANY php script at the moment, even though the http server is running, php.conf is in the right place, and php is installed. I simply assumed that the problem running the code locally was the same as the problem of running it remotely, and, indeed, the symptoms were all the same. I cannot reproduce those symptoms now, because the script won't run at all. (And the main symptom was that it would run but not report anything back.) But this is NOT how I noticed the original problem. Rather, the php script was in fact on another server. And that is what had worked for 15 years and suddenly stopped working. Now, after changing the setting in about:config, as recommended by Bob Owen, it DOES work when the php file is on the remote server. So I am not sure whether there is still a bug, because I am not 100% sure that the script in my original post EVER worked, although I think it did. But for my purposes the bug is fixed. Still, if anyone runs into the same problem, how would they ever learn to change that about:config setting? Shouldn't it be the default? And why would anyone want to set it to FALSE? Thus, I am not marking this as FIXED. If I figure out why I can't run any PhP scripts on my local computer anymore, I will test it again.
Here is a replacement for the test script. This works now and did not work before I changed the setting. I will leave the file there. <html> <body> <form action="http://www.sas.upenn.edu/~baron/welcome.php" method="post"> <!-- <form action="welcome.php" method="post"> --> Name: <input type="text" name="name"><br> E-mail: <input type="text" name="email"><br> <input type="submit"> </form> </body> </html>
(In reply to Jonathan Baron from comment #10) > Here is a replacement for the test script. This works now and did not work > before I changed the setting. I will leave the file there. > > <html> > <body> > > <form action="http://www.sas.upenn.edu/~baron/welcome.php" method="post"> > <!-- <form action="welcome.php" method="post"> --> > Name: <input type="text" name="name"><br> > E-mail: <input type="text" name="email"><br> > <input type="submit"> > </form> > > </body> > </html> Thanks Jonathan, this definitely looks like a duplicate of bug 1351358 then. The plan is to enable that pref by default, but I need to cut down the pages that would also get loaded in the same process before I'm happy to do that. Thanks for taking the time to get to the bottom of the issue you were seeing.
Status: NEW → RESOLVED
Closed: 8 years ago
No longer depends on: 1289718
Flags: needinfo?(gpascutto)
Flags: needinfo?(baron)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.