Session Management Issues Introduction

19.1 Introduction

Many web applicat ions int eract wit h users over a series of request s and, as a result need t o rem em ber inform at ion from one request t o t he next . A set of relat ed request s is called a session. Sessions are useful for act ivit ies such as perform ing login operat ions and associat ing a logged- in user wit h subsequent request s, m anaging a m ult iple- st age online ordering process, gat hering input from a user in st ages possibly t ailoring t he quest ions asked t o t he users earlier responses , and rem em bering user preferences from visit t o visit . Unfort unat ely, HTTP is a st at eless prot ocol, which m eans t hat web servers t reat each request independent ly of any ot her—unless you t ake st eps t o ensure ot herwise. This chapt er shows how t o m ake inform at ion persist across m ult iple request s, which will help you develop applicat ions for which one request ret ains m em ory of previous ones. The t echniques shown here are general enough t hat you should be able t o adapt t hem t o a variet y of st at e- m aint aining web applicat ions.

19.1.1 Session Management Issues

Som e session m anagem ent m et hods rely on inform at ion st ored on t he client . One way t o im plem ent client - side st orage is t o use cookies, which are im plem ent ed as inform at ion t ransm it t ed back and fort h in special request and response headers. When a session begins, t he applicat ion generat es and sends t he client a cookie cont aining t he init ial inform at ion t o be st ored. The client ret urns t he cookie t o t he server wit h each subsequent request t o ident ify it self and t o allow t he applicat ion t o associat e t he request s as belonging t o t he sam e client session. At each st age of t he session, t he applicat ion uses t he dat a in t he cookie t o det erm ine t he st at e or st at us of t he client . To m odify t he session st at e, t he applicat ion sends t he client a new cookie cont aining updat ed inform at ion t o replace t he old cookie. This m echanism allows dat a t o persist across request s while st ill affording t he applicat ion t he opport unit y t o updat e t he inform at ion as necessary. Cookies are easy t o use, but have som e disadvant ages. For exam ple, it s possible for t he client t o m odify cookie cont ent s, possibly t ricking t he applicat ion int o m isbehaving. Ot her client -side session st orage t echniques suffer t he sam e drawback. The alt ernat ive t o client - side st orage is t o m aint ain t he st at e of a m ult iple- request session on t he server side. Wit h t his approach, inform at ion about what t he client is doing is st ored som ewhere on t he server, such as in a file, in shared m em ory, or in a dat abase. The only inform at ion m aint ained on t he client side is a unique ident ifier t hat t he server generat es and sends t o t he client when t he session begins. The client sends t his value t o t he server wit h each subsequent request so t hat t he server can associat e t he client wit h t he appropriat e session. Com m on t echniques for t racking t he session I D are t o st ore it in a cookie or t o encode it in request URLs. The lat t er is useful for client s who have cookies disabled. The server can get t he I D as t he cookie value or by ext ract ing it from t he URL. Server- side session st orage is m ore secure t han st oring inform at ion on t he client , because t he applicat ion m aint ains cont rol over t he cont ent s of t he session. The only value present on t he client side is t he session I D, so t he client cant m odify session dat a unless t he applicat ion perm it s it . I t s st ill possible for a client t o t inker wit h t he I D and send back a different one, but if I Ds are unique and select ed from a very large pool of possible values, it s ext rem ely unlikely t hat a m alicious client will be able t o guess t he I D of anot her valid session. [1] [1] If you are concerned about other clients stealing valid session IDs by network snooping, you should set up a secure connection, for example, by using SSL. But that is beyond the scope of this book. Server- side m et hods for m anaging sessions com m only st ore session cont ent s in persist ent st orage such as a file or a dat abase. Dat abase- backed st orage has different charact erist ics t han file-based st orage, such as t hat you elim inat e t he filesyst em clut t er t hat result s from having m any session files, and you can use t he sam e MySQL server t o handle session t raffic for m ult iple web servers. I f t his appeals t o you, t he t echniques shown in t he chapt er will help you int egrat e MySQL-based session m anagem ent int o your applicat ions. The chapt er show s how t o im plem ent server-side dat abase- backed session m anagem ent for t hree of our API languages: [2] [2] Python is not included in the chapter because I have not found a standalone Python session management module I felt was suitable for discussion here, and I didnt want to write one from scratch. If youre writing Python applications that require session support, you might want to look into a toolkit like Zope, WebWare, or Albatross. • For Perl, t he Apache: : Session m odule includes m ost of t he capabilit ies you need for m anaging sessions. I t can st ore session inform at ion in files or in any of several dat abases, including MySQL, Post greSQL, and Oracle. • PHP includes nat ive session support as of PHP 4. The im plem ent at ion uses t em porary files by default , but is sufficient ly flexible t hat applicat ions can supply t heir own handler rout ines for session st orage. This m akes it possible t o plug in a st orage m odule t hat writ es inform at ion t o MySQL. • For Java-based web applicat ions running under t he Tom cat web server, Tom cat provides session support at t he server level. All you need t o do is m odify t he server configurat ion t o use MySQL for session st orage. Applicat ion program s need do not hing t o t ake advant age of t his capabilit y, so t here are no changes at t he applicat ion level. Session support for t hese API s are im plem ent ed using very different approaches. For Perl, t he language it self provides no session support , so a script m ust include a m odule such as Apache: : Session explicit ly if it want s t o im plem ent a session. I n PHP, t he session m anager is built in. Script s can use it wit h no special preparat ion, but only as long as t hey want t o use t he default st orage m et hod, which is t o save session inform at ion in files. To use an alt ernat e m et hod such as st oring sessions in MySQL , an applicat ion m ust provide it s own rout ines for t he session m anager t o use. St ill anot her approach is used for Java applicat ions running under Tom cat , because Tom cat it self m anages m any of t he det ails associat ed wit h session m anagem ent , including where t o st ore session dat a. I ndividual applicat ions need not know or care where t his inform at ion is st ored. Despit e t he differing im plem ent at ions, session m anagem ent t ypically involves a com m on set of t asks: • Det erm ining whet her t he client provided a session I D. I f not , it s necessary t o generat e a unique session I D and send it t o t he client . Som e session m anagers figure out how t o t ransm it t he session I D bet ween t he server and t he client aut om at ically. PHP does t his, as does Tom cat for Java program s. The Perl Apache: : Session m odule leaves it up t o t he applicat ion developer t o m anage I D t ransm ission. • St oring values int o t he session for use by lat er request s and ret rieving values placed int o t he session by earlier request s. This involves perform ing what ever act ions are necessary t hat involve session dat a: increm ent ing a count er, validat ing a login request , updat ing a shopping cart , and so fort h. • Term inat ing t he session when it s no longer needed. Som e session m anagers m ake provision for expiring sessions aut om at ically aft er a cert ain period of inact ivit y. Sessions m ay also be ended explicit ly, if t he request indicat es t hat t he session should t erm inat e such as when t he client select s a logout act ion . I n response, t he session m anager dest roys t he session record. it m ight also be necessary t o t ell t he client t o release inform at ion. I f t he client sends t he session ident ifier by m eans of a cookie, t he applicat ion should inst ruct t he client t o discard t he cookie. Ot herwise, t he client m ay cont inue t o subm it it aft er it s usefulness has ended. Anot her t hing session m anagers have in com m on is t hat t hey im pose lit t le const raint on what applicat ions can st ore in session records. Sessions usually can accom m odat e relat ively arbit rary dat a, such as scalars, arrays, or obj ect s. To m ake it easy t o st ore and ret rieve session dat a, session m anagers t ypically serialize session inform at ion convert it t o a coded scalar st ring value before st oring it and unserialize it aft er ret rieval. The conversion t o and from serialized st rings generally is not som et hing you m ust deal wit h when providing st orage rout ines. I t s necessary only t o m ake sure t he st orage m anager has a large enough reposit ory in which t o st ore t he serialized st rings. For backing st ore im plem ent ed using MySQL, t his m eans you use a BLOB or TEXT colum n. The rest of t he chapt er shows a session-based script for each API . Each script perform s t wo t asks. I t m aint ains a count er value t hat indicat es how m any request s have been received during t he current session, and records a t im est am p for each request . I n t his way, t he script s illust rat e how t o st ore and ret rieve a scalar value t he count er and a non- scalar value t he t im est am p array . They require very lit t le user int eract ion. You j ust reload t he page t o issue t he next request , which result s in ext rem ely sim ple code. Session-based applicat ions oft en include som e way for t he user t o log out explicit ly and t erm inat e t he session. The exam ple script s im plem ent a form of logout , but it is based on an im plicit m echanism : sessions are given a lim it of 10 request s. As you reinvoke a script , it checks t he count er t o see if t he lim it has been reached and dest roys t he session dat a if so. The effect is t hat t he session values will not be present on t he next request , so t he script st art s a new session. The exam ple session script s for Perl and PHP can be found under t he apache direct ory of t he recipes dist ribut ion, t he PHP session m odule is locat ed in t he lib direct ory, and t he JSP exam ples are under t he t om cat direct ory. The SQL script s for creat ing t he session st orage t ables are locat ed in t he t ables direct ory. As used here, t he session t ables are creat ed in t he cookbook dat abase and accessed t hrough t he sam e MySQL account as t hat used elsewhere in t his book. I f you dont want t o m ix session m anagem ent act ivit ies wit h t hose pert aining t o t he ot her cookbook t ables, consider set t ing up a separat e dat abase and MySQL account t o be used only for session dat a. This is t rue part icularly for Tom cat , where session m anagem ent t akes place above t he applicat ion level. You m ight not want t he Tom cat server st oring inform at ion in your dat abase; if not , give t he server it s ow n dat abase.

19.2 Using MySQL-Based Sessions in Perl Applications