How does the Back button in a web browser work? - browser

I searched the Web about this question but I found nothing:
What is the logic of the back button? What is happening when we hit the back button on a Web browser?
I really would like to understand more about that.

Your web browser keeps a stack (or list, if you will) of the web pages that you have visited in that window. Let's say your home page is search.example and from there you visit a few other websites: video.example, portal.example, and news.example. Upon visiting the last one, the list looks like this:
search.example -> video.example -> portal.example -> news.example
^
|
current page
When you press the Back button, the browser takes you back to the previous page in the list, like this:
search.example -> video.example -> portal.example -> news.example
^
|
current page
At this point you can press Back again to take you to video.example, or you can press Forward to put you at news.example again. Let's say you press Back a second time:
search.example -> video.example -> portal.example -> news.example
^
|
current page
If you now go to, say, example.com, the list changes to look like this:
search.example -> video.example -> example.com
^
|
current page
Note that both portal.example and news.example are gone from the list. This is because you took a new route. The browser only maintains a list the pages you visited to get to where you are now, not a history of every page you've ever been to. The browser also doesn't know anything about the structure of the site you're visiting, which can lead to some surprising behavior.
You're on a shopping site (shop.example, as a short example) that has categories and subcategories of products to browse through. The site designer has thoughtfully provided breadcrumbs near the top of the window to allow you to navigate through the categories. You start at the top page of the site, click on Hardware, then Memory. The list now looks like this:
search.example -> shop.example -> shop.example/hw -> shop.example/hw/mem
^
|
current page
You want to go back to the Hardware category, so you use the breadcrumbs to go up to the parent category instead of using the Back button. Now the browser list looks like this:
search.example -> shop.example -> shop.example/hw -> shop.example/hw/mem -> shop.example/hw
^
|
current page
According to the site structure, you went backward (up a level), but to the browser you went forward because you clicked on a link. Any time you click on a link or type in a URL in the address bar, you are going forward as far as the browser is concerned, whether or not that link takes you to a page that you've already been to.
Finally, you want to return to the main site page (shop.example). You could use the breadcrumbs, but this time you click the Back button -- it seems obvious that it should take you up one level, right? But where does it take you?
It's initially confusing to many users (myself included, when I happen to do exactly this) that it takes you "down" a level, back to the Memory category. Looking at the list of pages, it's easy to see why:
search.example -> shop.example -> shop.example/hw -> shop.example/hw/mem -> shop.example/hw
^
|
current page
To go back to the main page using only the Back button would require two more presses, taking you "back" to the Hardware category and finally to the main page. It seems so obvious to us programmers what's going on, but it surprises the heck out of regular users all the time because they don't realize that the browser doesn't know anything about the hierarchical structure of whatever website they happen to be on.
Would it be great if browsers would let site designers program the Back button to do the obvious thing (take you up a level) rather than whatever it does now?
A commenter asked whether the browser reloads the page or simply displays it out of its local cache.
The answer is it depends. Site designers can specify whether the browser should cache the page or not. For pages that are set as non-cached, the browser reloads the page from the server when you press Back, as though it was the first time you are visiting it. For cached pages, the browser displays it out of the cache, which is much faster.

I like to think of it as re-issuing my last request. If you performed a simple GET, it would probably return the same thing it did last time (minus dynamic content). If you had done a POST, you're going to resubmit the form (after confirmation) to the server.

I think the easiest way to explain this is in pseudocode:
class Page:
String url, ...
Page previous, next # implements a doubly-linked list
class History:
Page current # current page
void back():
if current.previous == null:
return
current = current.previous
refresh()
void forward():
if current.next == null:
return
current = current.next
refresh()
void loadPage(Page newPage):
newPage.previous = current
current.next = newPage # remove all the future pages
current = current.next
display(current)

The basic idea is to return to the last page or logical site division.
Looking at Gmail you'll see if you do a search and click a message then hit the back button it will take you back to the search that you did.
When you click it in most browsers it will either resend the last http request or will load a cache if the browser caches sites.

A history of pages viewed is kept in a stack-like form. When you "pop" the top three pages (A, B, C, for instance) and then go to a different page D, you cannot get to B again by hitting forward.

As a devoloper, you should make sure that your webapp works no matter how the browser handles the Back button :-) Does it resend the request? Is the new request identical to the old one, or does it differ in any way? Will browser ask user to confirm re-POST? What elements of the page will be re-requested and what loaded from cache? Will browser respect my cache-control headers?
Answers to these question depend on make, version of a browser and user settings. Design you software so that all this doesn’t matter that much.
Sorry for not very direct answer, but there are some straight answers here already.

a browser always stored the pages for its remembering and when we press the back button
it doesn't send the request to server for the previous page instead it just see its cache
where it stored the pages and it follow the LIFO rule that is why it give us that page first
on pressing the back button which we opened in the last

There is something I want to add as a complement.
When you hit the back button in your browser, or(alt+left) in chrome, the browser actually just loads the cached HTML file in the history.
it doesn't send another GET request to the server,
so when you go back in some ecommerce website and pass the password again it will throw exception to you.
it's true some web pages do not allow you to cache itself but that's rare, and in that case or the cache has expired, the browser will send the GET request instead of using the HTML from the cache.

The browser loads the last viewed page before the current one, and then follows any redirection that might happen?
I kind of seem to be missing the point of the question.

Related

XSS leaking into other parts of site

I've got a web application in which there are several XSS vulnerabilities on it, on the Profile Page for example there is a text box which is vulnerable to XSS along with the Messages Page. They both have text boxes yet when I add some XSS into the Profile Page, the pop up also comes up in the messages section and I can't figure out why. I've attached some screenshots for more information. If anyone can explain why this does this, I'd be very grateful.
The below Links are for visuals of the application
These are the source code images/files
Profile Page Source Code:
https://drive.google.com/file/d/1fA_Zoa7z4fdhBBzW2-e3Wm-fWF1qwXw7/view?usp=sharing
Message Page Code:
https://drive.google.com/file/d/1YApsri_3YSmUwlRfyajcebgpe26L37TZ/view?usp=sharing
You are inserting the saved data from this text box onto the messages.php page. If you right-click and inspect the "testtest" text, you'll notice a script was also added in there (the one you added earlier). By saving this server-side it allows it to be run each time the client loads the page because the browser still reads it as code to be ran. It should not - it should view it as text.
You'll notice that the first word in the background "test" is written, and the script has appeared. This is a blocking script, meaning no further code will be ran until you click the OK button in the dialog allowing the code to continue rendering the rest of the content on the page; hence why the second "test" word waits until you click okay before rendering the rest of the page.
Please let me know if I've missed anything out. Hope this helps

Navigation back through history

what's the best practice for navigating back many times (redirecting back)? I created a sessionScoped Bean with a stack but this spoils the navigation in case of having opened different tabs pushing wrong urls.
Navigation Example:
Page A -> Page B -> Page C
Page C -> Page B -> A
How to get the last url and get back and get back again? Ok I implemented viewParams now still don't know to navigate back.
The best model for handling navigation is to rely on the client browser remembering which URLs it has been to; this is the case for all frameworks not just JSF.
JSF makes it easy (and tempting) to maintain a lot of unnecessary state on the session. Keep your session scoped beans as light as possible and make sure that everything that is needed to properly initialise the web beans is encoded in the URL within view parameters. That way you don't have to re-invent the wheel and everything will work without surprises, regardless of how many tabs the client has open.

Limit Printing of Web Page

I'm in the beginning phases of developing a website. I want to be able to limit the amount of printing of web pages of circulars. These will be in an image format and usually consist of between 2 and 16 web pages. The circulars change each week.
Is there a way to limit the user to only 1 or X number of prints for each page and for each week? Is this easier done with standard web development or can it be done even easier in a content management system such as WordPress?
Not unless you have full control over the client-side.
You can TRY to prevent that SAME computer (via cookie) from
navigating to the same page twice.
If you are giving the user a unique ID to access the circular pages,
you can mark that ID as already having displayed the pages.
But there is simply no way to make sure that the user can't call the print calls in the browser.
One trick, which a js hacker could easily get around.. tie into the page printed event. The answers to that question talk about just how poorly the events are supported, and not cross-browser. If this browser has already had that event fire, nav away or change the #media rule for printing to return css making the whole page display:none (or some trickery).
As far as the actual print dialog ("Copies: x"), there's nothing you can do.

disable back button in browser

I have a website having frames. Clicking on button in one frame updates the pages to be loaded in other frames. Now when user press the back button few of the frames load previous pages. i want user not to move back to previous page.
I used the code history.forward() on onload event of all my pages.
This works fine when back is pressed. User got navigated to most recent page always.
But the case is suppose user navigate to number of pages by clicking on button in first frame which updates the pages to be loaded in other frames. After navigation user select a page from the list of browsing history, then it is move forward to only one page, not the last page he was viewing.
This Happens in IE.
In firefox it works fine. User can select any page from the browsing history, he is relocated to most recent page
My opinion is, you should review your concept, because you want to "reconfigure" the browser's navigation buttons. Disabling browser features is in my eyes old fashioned.
I used the code history.forward() on onload event
Try following this way:
In the head section, insert the javascript:
var historySize = history.length;
Then replace in onload event: history.forward() by history.go(historySize - 1). A positive value means move forward to a particular position in browser's history object (array).
I cannot guarantee that it will work, but it is worth to try out.
write this code between script tags
history.pushState(null, null, location.href);
window.onpopstate = function () {
history.go(1);
};

MOSS'07 - Page View Web Part Slows Menu Hovers

In our MOSS '07 site we have a page that contains just a Page Viewer web part in it that points to a site on another server. However, I've noticed that on that page (and any others that have a Page Viewer web part on it) our drop down menus and hover effects are super slow and completely max out the CPU on the visitor's computer (process is IExplorer.)
Through testing, I was able to determine that it doesn't matter what URL the web part is pointed to...just having the Iframe on the page seems to cause it (just setting the viewer to load Google's homepage--which is probably the simplest site I know--still causes the problem). If I go and remove the web part, the menus start functioning just fine again.
I attached a debugger to the process and stepped through the Menu_HoverStatic and called functions and it seems to have a hard time when assigning panel.scrollTop to zero in the PopOut_Show function.
Has anyone else noticed this? ...perhaps found a solution to it? I can't find where to edit PopOut_Show function on our server (I think it's a resource in one of the .NET DLLs) or else I'd just comment out that line as I don't think it's really important anyway...at least on our site.
I really like the ability to have web pages from another server hosted in our SharePoint site, but the performance on the hovers is agonizing... and, honestly, unacceptable. Depending on the resources of the user's computer, the hover effects can take 15 seconds to complete at times!!!!
Any suggestions would be really appreciated!
SharePoint's built-in JavaScript is probably making the browser wait until the IFrame within the Page Viewer Web Part has completely loaded. If you can see a status bar message that says "Please wait while scripts are loaded..." when you attempt to click on the page then that's definitely the problem.
Thank you for your reply. I was actually able to discover what the problem was (my appologies for not sharing it here with everyone when I did!)
The problem wasn't so much from having the IFRAME on the page, it was because I had set the zone to be 100% width and height. Because of a but in IE, trying to calculate the location of the dropdown was erroring (I don't remember what javascript function or call was exactly to blame, but I remember stepping through it with the debugger.) I believe it had something to do with "location offset" or something like that. My take at the time was that it was trying to position the dropdown menu on the screen, and the calculation for positioning it was failing.
To get around it, I had to set a javascript routine to programmatically set the height of the zone after the page loaded. Exactly setting the height prevented the dropdown problem in the menus. Of course, it wasn't ideal because if a user resizes the window, the IFRAME (or, more precisely, the zone it's in) doesn't resize with it. But, it was a suitable band-aid for the problem.
I'm hoping that IE 8 will fix this when it's released.

Resources