CS453: State in Web Applications (Part 1)
description
Transcript of CS453: State in Web Applications (Part 1)
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?