CS453: State in Web
Applications (Part 1)
State in General
Sessions (esp. in PHP)
Prof. 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 form
http://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 ecommerce 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?