I've got some PHP which handles a GET request via a query string. Once processing on that query string is done, it generates a page with the results.
So far so good. But the url in the browser keeps the query string, so e.g. if you hit reload, it again tries to process the GET.
So I'd like to generate the page, but return without the query string. I've tried setting the header() to the URL-minus-query, but that redirects (i.e. reloads) the page, rather than returning directly.
I'd think this is a common and easy task, but I can't find a solution...!
In case anyone runs across this post...
For the general case, given the difficulty of changing the url server-side, it's easiest to go through the effort to make it a POST, or use AJAX.
update: But in my case, it's a page where the user can change account information, which then needed to be reflected on that page. The answer in this case is simple: do the database updates first, then just redirect to the same page: parse_url($_SERVER['REQUEST_URI'],PHP_URL_PATH)
Regular PHP processing handles the rest.
The core problem is that you absolutely MUST NOT use GET for processing anything. GET should be safe and refreshing should have no side-effect. Generally the way people solve this is by:
Doing some processing with a POST request
Redirect to a 'results' page.
The most correct redirect status code for this is 303 See Other, but must frameworks will use 302 Found.
Related
I am working on a simple PHP site that involves needing to be able to forward a request made by the user to another page (note that I said forward, and not redirect). I am aware of how to redirect by manipulating the header variable, but I do not wish to do this, as explained below.
I am trying to write a very simple MVC-patterned mailing list app in PHP, drawing from my knowledge of the same in JSP. One of the things that I appreciated about JSP was that you could both forward or redirect a request. For my purposes, I need forward as I wish to keep the request parameters (whereas redirect will drop them).
Here is a description of what I wish to accomplish:
Retrieve input from a form (ie. /add.php)
Process the input in the page called by the form's action (ie. /process.php) and add a success message to the request object
Forward to another page (ie. /display.php) to display the success message in the request object
The only way I am aware of passing the request message to display is to add it to the request object and then access it from the forwarded page. However, the only way I have had success in transitioning to another page is through using the header method, which drops the request object (from what I can tell). I want to find a way to forward the request (object) to the new page, so that I can access the request variables from the new page.
Is there actually anyway to do this in PHP? Java's getRequestDispatcher.forward() is so nice, but I can't find an equivalent through searching. I've tried several similar questions, including the following, but I've never actually found one where both the question and the answer were what I wanted. Most of the answers seem to have something to do with cURL, but I don't want to actually retrieve a file, but simply forward a request in order to access the request object from another page.
Does PHP have an equivalent of Java's getRequestDispatcher.forward()?
Let me know if I should include anything else?
I believe you can do this with include. Before submitting the form just use, as inclusion, in main page:
include ("add.php"); - where the input forms are
after processing the information, include the display.php in the same way; using this, display.php will use same parameters from header, because is included in the same main page.
briefly: add.php, process.php and display.php will be modules for the mother page, but loaded in different state of form processing.
Hope it helps!
use curl with different method get,post. it will sent a request and also get back the response.
The most common method I see of passing messages to the end user from page to page is called session flashing.
This is when you store a variable temporarily in the session until it is read.
Assuming you already have sessions in use:
On process.php:
$_SESSION['message'] = 'Your data has been saved!';
On display.php:
if (isset($_SESSION['message'])) {
echo $_SESSION['message'];
unset($_SESSION['message']);
}
You could also store the entire Request object in the session.
So if I am aware, PHP provides just basic set of tools in this case. And there is nothing like "forward" in HTTP originally. It is just frameworks' abstraction/idea. There are two ways to achieve that: copying all params from request and doing new real HTTP request (with redirect) or internal forward: so framework would create fake request and call another controller and action without issuing a new physical HTTP request.
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.
If a user tries to log in and the login fails the page should display an error message to the user. There are two main ways I see to do this: use a form action on the HTML page and in the php script if the login information is incorrect redirect with header to the login page with a $_GET value like loginfailed. The login page would check for this value and if it exists it would display the error.
The second way I see to do this is not use a form at all and instead use JQuery to capture the submit button press and use AJAX to determine if an error occurs. The php file would echo back a status and the javascript file would interpret it and if it was loginfailed, it would use JQuery to append the error message on to the page.
Now I will go over what I feel the pros and cons of each method are.
Method 1 Pros:
Very simplistic with no need for JQuery, Javascript, and AJAX.
The error status is displayed within the URL as well.
Method 1 Cons:
Since there is a header call, a redirect is necessary. Also, the login page must be reloaded. It is a small page but it is a reload nonetheless.
The status message is displayed in the URL. This means that users can type in status messages in to the URL and receive error messages on the page for errors that did not actually occur. Is this a problem? Maybe. Maybe not.
Method 2 Pros:
Since it is using AJAX, there is no need to load another URL and thus, no extra page is loaded.
This method uses JQuery to update the page with the error message so no redirect is necessary.
The error status is not displayed in the URL.
Method 2 Cons:
Much more complex than the first solution.
An external javascript file is needed and must be loaded every time the login page is accessed regardless of whether or not it is used.
The default behavior of the submit button is overridden and annulled. Its only behavior comes from its interaction with the javascript file.
What would SO do? I would like to stay away from answers such as "it depends on how much traffic your site would have" if that would be at all possible.
Always use the simplest solution possible until/unless there's a very good reason to do otherwise. It's better to finish something that's maybe (and maybe not) less than ideal than to deliver something gold-plated eventually, maybe.
Also, I generally prefer to follow a progressive enhancement strategy, such that everything works without Javascript, and then add Javascript to make it work in an improved manner. This has the added benefit of being functional, even when/where Javascript is disabled.
I think you fail to grasp the matter.
Login is not something self-sufficient. It is used to change state of the site. But with no reload it will not be changed. So, page reload is required anyway. or user will have to do it manually to get access to the authorized section.
Is login the only site feature that uses JQuery/AJAX? If not - why you're worrying about loading this library once, when most likely it will be loaded at every page?
There are still clients with JS disabled, for various reasons. A good web application will always let these clients in, even at cost of less functionality.
The latter is the main question, most important one. Why to choose between two? Why not to use both? - one for compatibility and another for usability?
So, I'd suggest to create basic functionality using GET to pass come codes, not messages.
And optionally improve it with some AJAX bells and whistles but with JS-based reload on succesful login anyway
Which way of redirecting from one page to other is more reliable? I need to to have a link that bring the user to blank page where some php code is executed first(in the background) and then it redirects to the target page. I would like to make this seamless, so the user is not aware that he was redirected. I used javascript for that and it worked fine, but with Javascript disabled it simply won't work. Will php redirection work in this case? Can the header() function be used after some other php code has been executed? All advice appreciated.
Redirecting from PHP with header('Location: '.$URL); die; is the most dependable redirect you can do (since it works at the HTTP level).
The only catch is that you cannot redirect this way if you have produced any output already. This is something that you can avoid by simply thinking through your code flow and designing appropriately, but if push comes to shove you can shoehorn it into an existing code base by utilizing PHP's output buffering capabilities (basic example here).
Yes, header can be called after you run php code, just be sure you don't output any text. Then send a location header.
PHP redirection will work if you didnt send any output before the header. But yes, its easy to notice that you are redirected.
yes you can execute code with PHP before a redirect. Just be certain to use the right HTTP status code for the job. (I assume the default 302 will be appropriate, but you never know.)
This method will alert the client's machine of the redirect, but tends to be seamless enough that the average user wont notice.
Why not use AJAX to call a script that processes data, and then when that AJAX is complete you can redirect to the external page?
If all your first script does is calculate data and redirect, without returning any real content, then there's not a lot of point in forcing the page to be synchronously loaded and displayed with a normal HTTP request. I assume you are allowed to use JavaScript since that's in your question.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
To display this page, Firefox must send information that will repeat any action (such as a search or order confirmation) that was performed earlier.
Since application is built in such way that going Back is a quite common operation, this is really annoying to end users.
Basically, I would like to do it the way this page does:
http://www.pikanya.net/testcache/
Enter something, submit, and click Back button. No warning, it just goes back.
Googling I found out that this might be a bug in Firefox 3, but I'd like to somehow get this behavior even after they "fix" it.
I guess it could be doable with some HTTP headers, but which exactly?
See my golden rule of web programming here:
Stop data inserting into a database twice
It says: “Never ever respond with a body to a POST-request. Always do the work, and then respond with a Location: header to redirect to the updated page so that browser requests it with GET”
If browser ever asks user about re-POST, your web app is broken. User should not ever see this question.
One way round it is to redirect the POST to a page which redirects to a GET - see Post/Redirect/Get on wikipedia.
Say your POST is 4K of form data. Presumably your server does something with that data rather than just displaying it once and throwing it away, such as saving it in a database. Keep doing that, or if it's a huge search form create a temporary copy of it in a database that gets purged after a few days or on a LRU basis when a space limit is used. Now create a representation of the data which can be accessed using GET. If it's temporary, generate an ID for it and use that as the URL; if it's a permanent set of data it probably has an ID or something that can be used for the URL. At the worst case, an algorithm like tiny url uses can collapse a big URL to a much smaller one. Redirect the POST to GET the representation of the data.
As a historical note, this technique was established practice in 1995.
One way to avoid that warning/behavior is to do the POST via AJAX, then send the user to another page (or not) separately.
I have been using the Session variable to help in this situation. Here's the method I use that has been working great for me for years:
//If there's something in the POST, move it to the session and then redirect right back to where we are
if ($_POST) {
$_SESSION['POST']=$_POST;
redirect($_SERVER["REQUEST_URI"]);
}
//If there's something in the SESSION POST, move it back to the POST and clear the SESSION POST
if ($_SESSION['POST']) {
$_POST=$_SESSION['POST'];
unset($_SESSION['POST']);
}
Technically you don't even need to put it back into a variable called $_POST. But it helps me in keeping track of what data has come from where.
I have an application that supplies long list of parameters to a web page, so I have to use POST instead of GET. The problem is that when page gets displayed and user clicks the Back button, Firefox shows up a warning:
Your reasoning is wrong. If the request is without side effects, it should be GET. If it has side effects, it should be POST. The choice should not be based on the number of parameters you need to pass.
As another solution you may stop to use redirecting at all.
You may process and render the processing result at once with no POST confirmation alert. You should just manipulate the browser history object:
history.replaceState("", "", "/the/result/page")
See full or short answers