290 likes | 392 Views
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:
E N D
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 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?