CS453: State in Web Applications (Part 1) State in General Sessions (esp. in PHP) Prof. Tom Horton.

CS453: State in Web CS453: State in Web Applications (Part 1)Applications (Part 1)

State in GeneralState in General

Sessions (esp. in PHP)Sessions (esp. in PHP)

Prof. Tom HortonProf. Tom Horton

Readings

• Textbook:– Pages 155-158;

• On the web:

• On-line book:

State, Stateless, HTTP

• We say HTTP is stateless– From one request from client/server to the

next, the server:• Doesn’t remember anything• Can’t associate previous request with current

request

• Advantages: simpler protocol and implementations

• But we need state for real apps

State and Sessions

• State– Variable/info we store and have repeated

access to• “We” is client-side app and server-side app

• Session– A sequence of interactions for which we

remember state

One form of state: Cookies

• You remember cookies?• Clearly an example of state

– Stored on disk on client-side– Readable and writable by JavaScript– Readable and writable by server-side

scripts

• Issues?– Security, nuisance, abuse, expiration,

limitations on number, size, …

Where to Keep State?

• In server-side application– In Apache etc.?

• Why not a good idea?

– In memory in the server-side program?

• On the server’s file-system– In files or DBMS– Now: must have user-id or session-id,

and pass it around (and manage it)

Where to Keep State? (2)

• On the client?– On the file system: Cookies– In memory in the client

• Is this possible?• Advantages: can’t access through JavaScript,

hacking, etc.

• For any of these, passing things back and forth is still needed

Solutions

• Dynamic URLs– Input some information into the URL– Forms, CGI: GET method

• Cookies• Hidden input fields in forms

– Not displayed, but in HTML– Dynamic/changeable with JavaScript

• Java applets– Why does this solve the state issue?

PHP Sessions

• You’ve seen how PHP supports cookies• PHP also support sessions directly without

using cookies• The key ideas:

– Functions to start and end sessions– PHP and browser share a set of variables

“cleanly” with little effort on your part– For a single session

• While the browser is open, and…• Between your PHP calls to start and end session

What’s Shared

• $_SESSION– An associative array (super-global, like for

POST or cookies)

• A session-id– Get it with PHP function session-id() – But you don’t really need it

Starting a Session

• First line in script: start_session();

• Either– Creates a new session– Or “re-loads” current session

• Your browser knows if a session is active

– So pages using sessions should always start with this

Ending a Session

• At some point your know you’re done.So just call:

destroy_session();

• Cleans up $_SESSION and session-id

Session Variables

• Use $_SESSION as any associative array– Re-loaded with persistent values by

start_session()– As usual, not a good idea to use extract().– POST variables can over-write these– Don’t forget isset() function

Example

• Live on-line example

Web sessions

• Textbook: pages 285-286

• Custom URL method– First formhttp://www.com/path/script.cgi?args&sessionID

• The script does the work

– Second form:http:/www.com/path/sessionID/more/path

• The server knows how to handle this

Where to Store Info (Revisited)

• What’s a “three-tier” architecture– client, server, database

• E.g. browser plus PHP and MySQL on server– but other possibilities

• Other possibilities: federated systems– Cooperating distributed systems that handle

certain tasks– Examples: authentication (e.g. MS Passport),

wallets, credit card processing, shippers, etc.

Some Rules of Thumb

• Considering storing on the client when: – It’s info where security is crucial– Where OK if info not available when a

different machine is used– Where info used by more than one

application or page

Custom client application

• We think of web browser as the client application

• But businesses could supply a custom SW application

• Advantages/Disadvantages– Can keep more user-info secure– But: user must install/update client app– Can't use it anywhere on any system

Shopping Carts

• Textbook, Chap 16

Shopping Cart Basics

• What’s the metaphor here?– Just a “trolley” in a physical store?

Shopping Cart Basics

• To the business, cart eventually is like a sales order or purchase order– The latter is an accepted sales order

• Header data– Info on buyer, shipping, payment, etc.

• Line-item data– Item, SKU, quantity, price, etc.

Server-Side Shopping Carts

• Can be more complex in the real-world than you expect. Possible that:– Catalog stored/served separately than

Cart Storage– Order system separate– Orders (carts?) sent to other systems

(federated systems)

Persistence Issues

• How many carts?• By user:

– Wish-list, registry, etc. vs. “real” cart

• In system: Textbook example:– Session cart for anonymous user; session cart for

authenticated user; cart on catalog server

• Other saved carts– Company systems where a third-party approves

orders

Possible Features, Issues

• Quick orders– E.g Amazon one-click

• Configurators– E.g. ordering a computer at dell.com

• Order processing– To or by third-party organization

• Don’t forget: integrates with Catalog, Inventory

What Processing Is Done

• What do you remember?

What Processing Is Done?

• Shop, Add items

• “Edit” or update cart

• Checkout– Get shipping info– Get payment info and approve– Confirm order

• Send on to Purchasing

More Processing Done

• See text, pages 325f.• Note that these steps part of recognized

industry “pipelines” built into commercial e-commerce components/servers– Steps for verfication– Price adjustments; order (sub)totals– Taxes (!)– Shipping: Multiple shipments?– Validity of order?

Look and Feel

• What’s good? What’s not?

• Features you like?