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. :)
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'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?
I am using Laravel 5.2.15.
There are list of records in a webpage with Edit and Delete button with each record. I have two approaches for deleting the record
Use JQuery and send Ajax Request to server.
Place a form tag for delete button in each row.
I have following question
In case I use Approach 1, can it cause any issue when the site will be viewed from Android or iPhone? I have another option to do Server side validation using Request class.
In case of Approach 2, Will it make the page heavy? I am using Pagination, so 10 records will be displaced per page.
Please guide me if I should go with which approach or please suggest if both approaches are incorrect.
The questions you have don't really focus on the main reasons to choose one above the other. They differ mostly in how the request is sent to the server and how the page is refreshed to show the results.
Using Ajax is a very common approach and relies on using Javascript, a technology that has been available in all browsers for a very long time. Compatibility will not be a problem as most of the internet wouldn't function without it anyways (and you can even make it work using your second approach as a fallback mechanism). The request you sent is typically a HTTP DELETE request to a REST endpoint so that the server then knows to delete the record1. Upon receiving the success response from the server the page is responsible for updating itself by removing the row corresponding with the just deleted record, and possibly fetching new records to still have 10 rows on that page. No page refreshes required, but some Javascript required.
Your second approach is kind of old school in that the form you submit contains some kind of identifier such that the server knows what to do. This is a full page load and should be a HTTP POST request if you want to do it properly2. Following the Post/Redirect/Get idiom the server then sends a Redirect response so that the browser will then trigger yet another normal page load as GET request to show the user the updated list of records. You do not have to update the page manually by yourself, at the cost of having annoying page reloads (this isn't really expected anymore in the current day and age).
My advise would be to go with the first approach. It is the modern way of doing things and allows for having non-reloading pages. It does however require some additional work on the client side (in Javascript) to update the page accordingly.
As a side note, CSRF must be taken care of in both instances really. Always include a CSRF token with every 'update' action you perform on the server.
1 You have to program this yourself, of course :)
2 Browsers don't generally support anything other than GET and POST, although the HTTP specification allows for much more request methods.
It depends upon your requirements. But you should go with the 1st approch. If you will use 2nd approch the you will have to refresh the page since you can not handle the response. So basically if you delete 5 items the page needs to be refreshed 5 times and you may not send more than 1 delete request at a time. Now If you use 1st approch since It's ajax and javascript you can display appropriate message depending upon the result and no need of unnecessary page refresh.Plus as you mentioned you can do validaton using Request class. So you can handle bad or malicious request. And I am sure CSRF won't be that much of a problem since you can check whether the request is ajax or not using Request::ajax(). So 1st approch is better mostly because of that no page refresh.
Both approaches are fine ;)
But 2nd approach would be better than first one; Using this approach you can prevent CSRF attacks too;
I would suggest you to use method 1 with certain modifications.
Use get request to delete the record.
Send a CSRF token and dont forget to encrypt your id for the record
add your delete URL to href
Then when you do ajax request, use the url from href and you could send some additional parameter like is_ajax=1, but laravel already checks for the jquery header so Request::isAjax() method will let you know if the request was an ajax request or normal request.
Now all you need to do is send different response for ajax and normal request.
HOPE THIS HELPS :D
Another drawback of your second approach which haven't been mentioned is displaying validation errors. Specifically from your edit and even your delete actions.
If you have multiple forms for each set of data showing errors from validation would be a pain. But if you follow approach number 2 just by getting the reference of the row element submitted, you could easily append an alert div if ever an error from validation has occurred.
as for the delete action, somebody else might have already delete some shared data so you might also want to tell the user somebody already threw this out.
What is PHP action? Is there anything called as PHP action? I tried to google it and look up different web forums but was not able to find anything related to this. A recruiter had sent me an email where he wanted someone with skills/experience in "PHP action". Just curious.
If it stood on its own like that, my guess is the recruiter doesn't know what he's talking about. Maybe it was a copy+pasting error from "Actionscript" or something.
"PHP Action" is not a defined term. At least not one I have ever heard of.
My tendency would be to respond anyway, and then sort the details out later when getting interviewed by the actual employer.
Action is a term used throughout the Symfony Framework 1.x, perhaps he was referring to that. They are basically page controllers. Few examples:
// apps/myApp/modules/myModule/actions/actions.class.php
public function executeIndex() {}
public function executeResult() {}
he Action attribute is crucial. It means, "Where do you want the form sent?". If you miss it out, your form won't get sent anywhere. You can send the form data to another PHP script, the same PHP script, an email address, a CGI script, or any other form of script.
In PHP, a popular technique is to send the script to the same page that the form is on – send it to itself, in other words. We'll use that technique first, but you'll see both techniques in action.
So we're going to be sending the form data to exactly the same page as the one we have loaded – to itself. We'll put some PHP on the page to handle the form data. But for now, save your work again and then click your submit button. You won't see anything different, but you shouldn't see any error message either!
Once your script has an Action attribute set, you can then Submit it. Which we'll see in the next part.
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?