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

State in GeneralState in GeneralSessions (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?