Action called from many other places, how to handle a "Back" button? - php

I have an action (view for example) in a controller that is called from multiple other actions in other controllers. How is the best way to create a "Back" button that will take me back to the page that got me here?
I've used named parameters like "back_controller" and "back_action" and that works fairly well but they get awkward when the page has a form that gets submitted. I have to be sure to pass those parameters as hidden fields or in the form url and then look for them after the form has been processed.
Is there some kind of stack or other solution that anyone else has come up with that handles this situation better? I see this problem in a lot of my projects and I've yet to come up with a good solution.

I don't completely understand your question, but this may be helpful:
If you need to redirect to the referer page you can use:
$this->redirect($this->referer());
http://book.cakephp.org/view/425/redirect

I don't believe in back buttons. That is a feature that the browser does quite well and you would be better off having buttons always taking you to specific destinations rather than back.
If you must have a back button, you could create a history stack in the session. When a page loads you just push that page on the history (you will want to make sure you don't push the same page on the stack multiple times). You could create URL like /back who's sole job is to redirect the user to the last page they were on.

$_SERVER['HTTP_REFERER']

Related

Form submission without revealing form content

I run a website which includes several radio streams. I have set up icecast to request .htaccess account in order to authenticate and start streaming. There is the same account for all streams. I submit the form (it is hidden via css) with jquery once the page loads so the user does not have to know the account nor submit the form.
The problem is that form information are being revealed if user views source. Is there any way to hide these information? Searching the internet what most people say is that this is not possible because browser needs to be able to clearly read these information in order to function properly. Anyone know any way, if it is possible?
I ended up creating the form (document.createElement) on page load with jquery, submitting it (.trigger("click")) and then removing it (.remove()). In addition I obfuscated the jquery code with the tool found here Crazy Obfuscation as #André suggested. That way user cannot see the htaccess username and password in Page Source nor find it using "inspect element" or firebug.
Personally, I need a bit more information to clearly deduct a solution for your issue, I hope you can give me that.
However, have you tried simply .remove()ing the form after submission? That way it gets submitted on page load and then gets removed so by the time the page loads and the user clicks view source, he will not be able to see it. He can, of course, disable JS for example, or any other workaround, but this is a very quick fix with the amount of information we have.
You can not directly hide values in 'view source'. Similarly when the form is being submitted, using tools like 'fiddler' the user could view the values. If you want to really hide them what you can do is never have those values show in the form. You could try techniques like encrypting those values on server or something if it never needs to be displayed to the user in the web page.

Reload Methods: Complete Ajax Solutions

My web application utilizes page reloads in places where the page structure changes.
For content changes initiated by the user it is all handled by Ajax.
However I'm planning on removing all the page reloads and replacing them with ajax calls that simply update the page using innerHTML for the body and head tags.
To do this I know have to manually call functions that are normally called by the onload event.
When I am done I will have a complete ajax application. My question is, is this standard practice now....I see a lot of applications where you do something and the whole page reloads, where even common elements are reloaded.
For example go to Apple.com and hit on the first button you see "Store"...you will see the whole page reload even the menu bar that does not change is reloaded wasting bandwidth..
Because I don't see other people using complete ajax solutions...I wonder if I am headed down a wrong path.
My question?
Is a complete ajax based web application best practice? (of course file uploads aren't supported, omitting this, is it best practice).
If so why do big sites not do it? I see few sites that actually employ ajax instead of page reloads.
There are a number of reasons not to go fully ajax. A few are:
If the user refreshes the page they'd be sent back to the home page;
if they pressed the back button, they'd go back to the previous site
they visited.
Search engines won't be able to index anything past the home page.
Anyone without javascript enabled or on IE 6 (or it's equivalent) wouldn't be able to use the site.
Lastly, it can be hell to debug a problem -- I went full ajax on a project a while ago and ended up regretting it.
If none of the above are important to your project, and you're looking to do something different, then by all means -- the real question you need to ask is "does the added complexity justify the savings in bandwidth?".
The concept of ajax is reload certain content of the page when you don't need to change all the content.
Your example of apple.com: it isn't a best practice to use ajax in navigation, because the history of browser don't handle this (use the back button of the browser and the navigation will not respond if you use ajax, keep that in mind).
If you have a box with testimonials and want them to change from time to time, so it's a good place to use ajax, avoiding the whole page to reload.
You can also have a static page with all testimonials to let search mecanisms to index that content.
Example of big sites? The search of google. When you type only the box of results is reloaded to view one preview.
So you have to choose when use and when not use ajax.

Browser goes Back after PHP page is executed

I have a form which sends data to a proccess page. Is it possible when the code in the process page is executed for the browser to jump back to the previous page?
EDIT
The reason i want this, is because i have a set of parameters which contains checkboxes. These parameters are echoed out via a while loop. I have a table where it shows which of those parameters are active. I would like to check the checkboxes by defualt where the corresponding parameter is in the table.
|||||||||||||||||||||||||||||||| Example ||||||||||||||||||||||||||||||
PARAMETERS:
T-Shirt: checked
Distance: checked
Race: unchecked
TABLE (parameters)
• T-Shirt
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||the example above checks the box if it already exists in the parameters table. When the user clicks back after the process page, the boxes he selected is checked.
Hope i am clear enough
Regards
I think a nice solution might be to implement a front controller for your webbage, a central script to include the appropirate page. Using a system like that, the user stays on the same page all the time even when other pages are loaded.
I haven't used a front controller in quite some time, so I won't write examples due to potential errors and poor coding. You can probably find some examples using google though, I wouldn't be surprised if the subject has been brought up here on Stackoverflow before either.
Even though I'll have to point out Griffin's solution is the best, if you're dead set on a redirect, simply have your PHP script execute the following lines:
echo '<script>document.history.go(-1);</script>';
die();
Or even
die('<script>document.history.go(-1);</script>');
It's a dirty solution, so I must advise against it.

Make all hyperlinks on a PHP page, post a form end then redirect

The short version of what I am looking to do is make a "safe" and idiot-proof page, at least as much as possible.
I have researching the best way to make every hyperlink on a page (ie. standard menus used on the page or any other hyperlinks outside of a HTML form) submit/POST the form information and then redirect to the page clicked on.
For some reason not all users remember the "Save" button before clicking on something else. Then they are upset because they didn't save their information. I would much rather have all the information be saved before sending them on to the hyperlink's URL.
Helpful information:
- This is on a PHP based project.
- I have already put in place code to "detect" what kind of page is in use and if the feature is needed.
- I have header() redirects in some places for other items, so that is nothing new.
- I have looked at javascripts to add, when needed, so that the form is POSTed, and found some options for that.
At this point I can't get the final steps put together, such as a javascript that would POST the information AND store the URL that the hyperlink was supposed to go to. Process the POST information and then redirect to the stored URL.
Dream Example:
onclick="submitformandforward("Example_form", "http://example.mysite.com/example_page.php?querystring=Y")"
Any suggestions, tips, examples, etc are warmly welcomed!
Thanks.
KH
Javascript is the tool you require...
remember some people may have it switched off...
Wehn some clicks a link - check that the form values have been altered - if not carry on - if they have inform that that changes need saving...

Track when user hits back button on the browser

Is it possible to detect when the user clicks on the browser's back button?
I have an Ajax application and if I can detect when the user clicks on the back button I can display the appropriate data back
Any solution using PHP, JavaScript is preferable. Hell a solution in any language is fine, just need something that I can translate to PHP/JavaScript
Edit: Cut and paste from below:
Wow, all excellent answers. I'd like to use Yahoo but I already use Prototype and Scriptaculous libraries and don't want to add more ajax libraries. But it uses iFrames which gives me a good pointer to write my own code.
One of my favorite frameworks for doing this is Yahoo!'s Browser History Manager. You register events and it calls you back when the user returns Back to that state. And if you want to learn how it works, here's a fun blog entry about the decisions Yahoo! made when designing it.
There are multiple ways of doing it, though some will only work in certain browsers. One that I know off the top of my head is to embed a tiny near-invisible iframe on the page. When the user hits the back button the iframe is navigated back which you can detect and then update your page. Here is another solution.
You might also want to go view source on something like gmail and see how they do it.
Here's a library for the sort of thing you're looking for by the way
There's no way to tell when a user clicks the back button of presses the backspace key to go back in the browser, however there are other events that happen in a certain order which are detectable. This example javascript has a reasonably good method for detecting back commands:
The traditional way, however, is to track user movement through your site using cookies or referrer pages. When the user goes to page A, then page B, then appears at page A again (especially when there's no link on B to A) then you know they went back - A can detect this and redirect them or otherwise.
The Yahoo User Interface Library, my personal favorite client-side JS library, has an excellent Browser History Manager that does exactly what you're asking for.
The simplest way to check if you came back to a cached version of your page, which needs to be refreshed, is to add a hidden input element that will be cached, and you can check if it still has its default value.
Just place the following inside your body tag. I place mine right before the end tag.
<input type="hidden" id="needs-refresh" value="no">
<script>
onload=function(){
var e = document.getElementById("needs-refresh");
if (e.value === "yes")
location.reload();
e.value = "yes";
}
</script>
I set a variable $wasPosted in $_SESSION with value false.
All my posts go via the same php file, and set $wasPosted to true.
All header(location:) requests are preceded by setting $wasPosted to true.
If $wasPosted is false then the page was loaded after use of the backward or forward buttons.
The dojo toolkit has functionality to deal with this in javascript. I don't think there is any good way to handle it in pure PHP.
Here is the docs page they have: http://dojotoolkit.org/book/dojo-book-0-9/part-3-programmatic-dijit-and-dojo/back-button-undo

Categories