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

Readings Textbook: –Pages ; 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 Custom URL method –First form The script does the work –Second form: 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?