I'm expecting a strange error lately.
I'm tracking every error (even soft) from my website and something strange is happening.
1% of user that compile a form sent via post send empty data. Nothing in the post not even the hidden values or the name of the fields. There is also a js validation in this form that could prevent an empty submit.
I'm using Laravel + Nginx. I've track all data but the problem seems not coming from Laravel (I'm tracking POST submission data as first thing in the index.php of laravel and it looks already empty). I've added post data in nginx logs and it looks empty when the error occurs.
It affects mostly mobile devices (of all kind) but also desktop (of all kind).
I've tracked all different form and error come from all forms indistinctly that made a post to this url.
Any idea?
Related
I have been working on a controller that makes modifications on existing data. The initially received response gives the client a view where client can fill a form and submit it as POST request. After the POST request is handled, client gets redirected to the same page where he/she filled the form.
The problem here is, form is not actually part of that view that is acquired with GET request. The form is being loaded with the help of a button and AJAX request to another route. This part is important: form is not part of the view, it is loaded with an AJAX request on that view.
So, what is the problem? The problem is, I'm currently providing invalid data to the form so I can check out the validation system is working correctly. I should to feed client back with proper error messages and load the form with old inputs that the client has provided. But when I try that, I get the old input and errors on the view, after submitting the form. That's great, but once I click that button to load the form into the page and open it, there's no old input or error data. That is probably because Laravel's old input data and errors bag is only available for the next request. When the controller redirects the client to the route that responses with the view, it receives the error and old input data but when it loads the form by making an AJAX request, they are already cleaned.
To overcome this problem, I have been resetting the old input and errors with the same values for the next request, like below:
#php
session()->flash('errors', $errors);
session()->flash('_old_input', request()->old());
#endphp
This solution was working good on the page that loads the creation but I also have the same mechanism for editing the added resource. Refreshing the old input and error data works for creating phase but doesn't work as well for editing. I have made sure I'm doing everything same for both actions, I checked it out but I couldn't find why there's such inconsistent behaviour. So I dediced to look up for another solution.
How do I make error data and old input data persistent? I will probably need to remove these session datas after the controller done its job or after showing the data to the user with the form view. How do I do that?
I have a small app running on Symfony 2.4, which works perfectly fine on my local setup.
But I deployed it on a shared-web hosting service (OVH), and lately, all the forms stopped working. Yes, even the symfony parameters configurator.
On each and every form, what happens is: the submission process goes fine, as much as I can see. In Firebug, I can see that each parameter of the POST request is correctly filled and sent to the right action. But after that, I get redirected back to the form, all fields are empty, and I get a validator warning above each required field saying "please fill up ". Which I did!
Even the hidden csrf_token seems to be erased. I used to think csrf_protection was the problem (because of the "invalid csrf token" warning), but I disabled it and it turns out it's just an effect of the fields being erased somehow.
Anyone knows how to investigate this?
We are developing two separate sites on Symfony2 and encountered a strange problem on both of them when processing submitted forms.
Both sites have an action that is used for both displaying the form and handling submission. As it handles both GET and POST requests, $this->getRequest()->getMethod() is checked. If it is GET, we display the form. If it is POST, we persist it into an entity.
However, getMethod() seems to always return GET even when posting the data. I know the request method should be POST because the browser's network inspector says it sent the form as a POST request and var_dump($_POST); outputs the contents of the form we just submitted.
The sites are running on separate servers, both CentOS 6.3. I have a third similar server running a third site which handles the submissions fine. What could be causing this?
I've had such a problem several times and tried different approaches to it. Here's my last one:
public function formAction(Request $request)
{
}
{% render 'Bundle:Controller:form' with {'request': app.request} %}
Note that you need to get the request as a parameter in this case — instead of fetching it from the container. If you're using Symfony idiomatically, then you're doing that already.
If you'll ever find a better way of solving this problem, I'm eager to know it. :)
I have been using Uploadify in my PHP application for the last couple months, and I've been trying to track down an elusive bug. I receive emails when fatal errors occur, and they provide me a good amount of details. I've received dozens of them. I have not, however, been able to reproduce the problem myself. Some users (like myself) experience no problem, while others do.
Before I give details of the problem, here is the flow.
User visits edit screen for a page in the CMS I am using.
Record id for the page is put into a form as a hidden value.
User clicks the Uploadify browse button and selects a file (only single file selection is allowed).
User clicks Submit button for my form.
jQuery intercepts the form submit action, triggers Uploadify to start uploading, and returns false for the submit action (manually cancelling the form submit event so that Uploadify can take over).
Uploadify uploads to a custom process script.
Uploadify finishes uploading and triggers the Javascript completion callback.
The Javascript callback calls $('#myForm').submit() to submit the form.
Now that's what SHOULD happen. I've received reports of the upload freezing at 100% and also others where "I/O Error" is displayed.
What's happening is, the form is submitting with the completion callback, but some post parameters present in the form are simply not in the post data. The id for the page, which earlier I said is added to the form as a hidden field, is simply not there in the post data ($_POST)--there is no item for 'id' in the $_POST array. The strange thing is, the post data DOES contain values for some fields. For instance, I have an input of type text called "name" which is for the record name, and it does show up in the post data.
Here is what I've gathered:
This has been happening on Mac OSX 10.5 and 10.6, Windows XP, and Windows 7. I can post exact user agent strings if that helps.
Users must use Flash 10.0.12 or later. We've made it so the form reverts to using a normal "file" field if they have < 10.0.12.
Does anyone have ANY ideas at all what the cause of this could be?
IOError: Client read error (Timeout?)
I got the same error a lot although my server side is python/django. I assumed it was the client timing out, but looking back though the logs for you now there seems to be a coincidence of this ceasing when I changed something in the authentication routines. Is it possible that the server is receiving the file but then refusing to write it to storage?
Also, you aware that several flash clients do not send cookies? You have to work around it by injecting the session keys into uploadify's 'scriptData' variable.
x--------------------------------
Edit. This python/django code starts off the routine to which uploadify submits itself:
# Adobe Flash doesn't always send the cookies, esp. from Apple Mac's.
# So we've told flash to send the session keys via POST. So recreate the
# session now. Also facilitates testing via curl.
cookie_name = settings.SESSION_COOKIE_NAME
if request.member.is_anonymous() and request.POST.has_key(cookie_name):
# Convert posted session keys into a session and fetch session
request.COOKIES[cookie_name] = request.POST[cookie_name]
SessionMiddleware().process_request(request)
# boot anyone who is still anonymous
if request.member.is_anonymous():
response['message'] = "Your session is invalid. Please login."
return HttpResponse(simplejson.dumps(response), mimetype='application/json')
Uploadify might alter the form. Take a look at the html/DOM tree of the form at the time when uploadify has finished and is calling your callback.
Have you tried using Live HTTP Headers in Firefox to see if there is some kind of rewrite happening that is causing the post data to be lost?
i have create a form (so it's PHP and HTML hybrid-code). it has ability to send '$_POST'. And when i click it, it work perfectly on sending and displaying input.
But there's something happening when i click Ctrl+R in firefox for represhing the page. I got this confim dialog : "To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier"
my question
what is it, (this confirm dialog ?)
what i have to do on my code so it able to suppress this dialog ?
You probably have created an HTML page that contains a <form>. The form is used to send data to the HTTP server (that is, the webserver that hosts your site).
The HTTP protocol defines different request types used to send data to the server and to retrieve data from the server. The most used are GET and POST. You must learn about all this if you want to be anything more than a very bad PHP programmer, which is unfortunately (or fortunately, if you are on the hacker side) very common.
Your problem is that Firefox has arrived on the page you are talking about after sending a POST request. If you reload the page, it has to send the same data again in the form of a POST. Due to the conventions on what a POST request should be used for (usually to modify data on a database), the browser asks the user if he is sure about what he wants to do.
There are mainly two options to circumvent this:
Change the form method to GET; or
Use a redirection after the POST.
To use the first method, you could simply add a method="get" parameter to your form tag:
<form action="senddata.php" method="get"> ... </form>
To use the second method, you simply redirect the user after the POST request, using something like
header("Location: blahblahblah")
The most used pattern is the POST-Redirect, that is, the second method I told you about. There are many security implications on using GET to change data on a database (if you are interested on that, and you should be, as every PHP programmer should, read about XSRF).
Submitting a form (sending a POST request) is commonly used to confirm an order on eCommerce sites. Therefore, submitting it twice would submit the order, twice. Therefore browsers, tend to ask for confirmation that a user wants to send the POST request again.
In order to prevent this, you need to make the refresh do a GET request instead of a POST request. To do this, simply redirect to the same page after processing the form.
header("Location: /path/to/self");
This will make it so when the user hits refresh, it will be sending a GET request instead of a POST request, and it won't prompt for confirmation.
To clairify, it goes like this:
Form gets sent via POST (User clicks on form)
Form gets processed
User gets redirected to the same page (via GET)
User now will be refreshing a GET request instead of a POST request.
I guess whenever your form (php, asps, static html etc) contains post information that may either form field infor or other, is sent to the server via firefox, it displays such a message before sending the data again to server. it serves as a security protection from Mozilla developers. I guess it can be disabled via about:config but it is not recommended to so.
Also it is a normal behaviour. It should be like this and have been like this for a fairly long time in firefox.
You may like to have a look here:
http://forums.mozillazine.org/viewtopic.php?f=38&t=682835&st=0&sk=t&sd=a&hilit=Firefox+must+send
alternatively use GET instead of POST to send your data...
Regards
If the form was submitted successfully, answer with the status code 303:
header('Location: http://www.example.com/', TRUE, 303);
This forces the browser to use a GET request for the resulting page. A reload won’t send any POST data, and no pop up is shown.