1 / 29

CS453: State in Web Applications (Part 1)

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:

eilis
Télécharger la présentation

CS453: State in Web Applications (Part 1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Readings • Textbook: • Pages 155-158; • On the web: • On-line book:

  3. 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

  4. 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

  5. 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, …

  6. 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)

  7. 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

  8. 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?

  9. 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

  10. 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

  11. 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

  12. Ending a Session • At some point your know you’re done.So just call: destroy_session(); • Cleans up $_SESSION and session-id

  13. 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

  14. Example • Live on-line example

  15. 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

  16. 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.

  17. 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

  18. 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

  19. Shopping Carts • Textbook, Chap 16

  20. Shopping Cart Basics • What’s the metaphor here? • Just a “trolley” in a physical store?

  21. 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.

  22. 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)

  23. 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

  24. 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

  25. What Processing Is Done • What do you remember?

  26. 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

  27. 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?

  28. Look and Feel • What’s good? What’s not? • Features you like?

More Related