The URL encodes a query that identifies a particular stock, and presumably, the script stockprice.php uses the query to display the current stock price of the company. The URL can be bookmarked because it contains all that is needed to generate the stock price page for the given company code. An alternative site may collect the company code using a
<form> and, when the form is submitted, use a session variable to hold the company code as a query. The script that generates the stock price page reads the session variable, looks up the current price, and generates the result for the entered company code. If a user bookmarks the session-based stock price page and comes back in a week, the session that stored the company code is unlikely to still exist, and the script fails to display the desired company's stock price.
Sometimes bookmarking a page makes no sense. Consider an online banking application that allows transfer of funds between two accounts. A user would log in to the application, then request the transfer page that collects the source and target account details in a
<form>. When that
<form> is submitted, a confirmation page is shown without actually performing the transaction. Revisiting this page through a bookmark has no meaning if the transaction was subsequently confirmed or canceled. Generally, the pages generated from applications such as online banking can't be bookmarked because of the reliance on session variables. Session management in such applications is often tied closely to authentication, a topic explored further in Chapter 9.
Sessions can provide a way for a hacker to break into a system. Sessions can be open to hijacking; a hacker can take over after a legitimate user has logged into an application. There is much debate about the security of session-based applications on the Web, and we discuss some issues of session security in the next chapter.updated