Theory
વેબ તમને તરત જ ભૂલી જાય છે
વેબ વિશેની અકળાવનારી હકીકત આ રહી: HTTP stateless છે. દરેક request સાવ એકલો ઊભો રહે છે; server આગલા request વિશે કુદરતી રીતે કશું યાદ રાખતું નથી. એટલે વિદ્યાર્થી FestConnect માં log in કરીને પછીના page પર click કરે ત્યારે મૂળભૂત રીતે server ને એ log in થયેલો છે એની કશી યાદ હોતી નથી.
એ ચાલે નહીં, કારણ કે apps ને યાદ રાખવું જ પડે કે તમે કોણ છો, તમારા cart માં શું છે, તમે શું પસંદ કર્યું. Requests વચ્ચે data યાદ રાખવાની રીતોના સમૂહને state management કહે છે, અને આ પાઠ એની મુખ્ય રીતો પર નજર ફેરવે છે.
Theory
State રાખવાની બે જગ્યાઓ
State બે જગ્યાએ રહી શકે છે, અને આ ભાગલા જ આખા વિષયની ચાવી છે.
Client બાજુનું state મુલાકાતીના browser માં કે URL માં સંઘરાય છે અને દરેક request સાથે આવ-જા કરે છે: cookies (નાનો key-value data જે browser સંઘરે છે અને ફરી મોકલે છે), query string (URL માં ? પછી આવતી કિંમતો), hidden fields, અને view state (page ના પોતાના controls ની કિંમતો, જે postbacks દરમિયાન સચવાય છે).
Server બાજુનું state server પર સંઘરાય છે અને browser પાસે એનો ફક્ત સંદર્ભ હોય છે: session state (કોઈ એક ચોક્કસ વપરાશકાર માટેનો data) અને application state (બધા વપરાશકારો વચ્ચે વહેંચાયેલો data).
At a glance
| રીત | ક્યાં સંઘરાય છે | પહોંચ અને સામાન્ય વપરાશ |
|---|---|---|
| Cookie | Browser (client) | મુલાકાતો વચ્ચે વપરાશકાર દીઠ નાનો data (જેમ કે 'remember me') |
| Query string | URL (client) | Pages વચ્ચે કિંમત મોકલવી (જેમ કે ?eventId=12); દેખાય છે, ગુપ્ત વસ્તુ માટે નહીં |
| View state | Page પોતે (client) | Page ના controls ની કિંમતો એના પોતાના postbacks દરમિયાન સાચવવી |
| Session | Server, વપરાશકાર દીઠ | કોણ log in થયેલું છે, cart; વપરાશકારના session સુધી ટકે છે |
| Application | Server, વહેંચાયેલું | બધા માટે સામાન્ય data (જેમ કે મુલાકાતીઓની ગણતરી) |
Formula
Client બાજુનું સામે server બાજુનું state
Client બાજુ (cookies, query string, view state): data browser માં કે URL માં સાથે સાથે ફરે છે. એ server ની કશી memory વાપરતું નથી, પણ વપરાશકારને દેખાય છે કે એની પહોંચમાં હોય છે, એટલે ગુપ્ત વસ્તુઓ કે વપરાશકારે બદલવી ન જોઈએ એવી વસ્તુઓ ત્યાં કદી ન મૂકો.
Server બાજુ (session, application): data સલામત રીતે server પર રહે છે; browser પાસે ફક્ત એની તરફ ઇશારો કરતી નાની id હોય છે. એ વધુ સલામત છે અને વધુ સમાવી શકે છે, પણ એ server ની memory વાપરે છે. સંવેદનશીલતા અને કદ પ્રમાણે પસંદ કરો: નાનું અને હાનિરહિત હોય તે client બાજુ જઈ શકે; ખાનગી કે અગત્યનું હોય તે server બાજુ જ રહેવું જોઈએ.
Practical
Session (વપરાશકાર દીઠ) અને cookie
// SERVER-SIDE: remember the logged-in student for this user's session
Session["studentName"] = txtName.Text;
// ...on a later page, read it back:
string who = Session["studentName"] as string;
// CLIENT-SIDE: store a small preference in a cookie for 30 days
var prefs = new HttpCookie("theme", "dark");
prefs.Expires = DateTime.Now.AddDays(30);
Response.Cookies.Add(prefs);
// Read a value passed in the URL (?eventId=12)
string eventId = Request.QueryString["eventId"];Quiz
વિદ્યાર્થી pages વચ્ચે ફરે ત્યારે કયો વિદ્યાર્થી log in થયેલો છે એ FestConnect ને યાદ રાખવું છે, અને એ server પર સલામત રીતે રાખવું છે. કઈ રીત સૌથી બંધબેસતી છે?
- Query string, એટલે કે વિદ્યાર્થીનું નામ દરેક URL માં મૂકવું
- Session state, જે વપરાશકાર દીઠ data ને એના session ના સમય પૂરતો server પર સંઘરે છે
- વિદ્યાર્થીનો password રાખતું cookie
- Application state, કારણ કે એ બધા વપરાશકારો વચ્ચે વહેંચાયેલું છે
Show the answer
Session state, જે વપરાશકાર દીઠ data ને એના session ના સમય પૂરતો server પર સંઘરે છે
Session state કોઈ એક ચોક્કસ વપરાશકારનો data SERVER પર સંઘરે છે અને એના session ના સમય સુધી એના બધા requests દરમિયાન ટકે છે, જે 'કોણ log in થયેલું છે' એ માટે બરાબર છે. વિકલ્પ A નબળો છે: query string data ને URL માં મૂકે છે, જે દેખાય છે, સહેલાઈથી બદલી શકાય છે અને દરેક link ને ગૂંચવે છે, એટલે ઓળખ માટે ખોટો છે. વિકલ્પ C જોખમી છે: password ને cookie માં કદી ન સંઘરો; cookies browser માં રહે છે અને વંચાઈ કે ચોરાઈ શકે છે. વિકલ્પ D ખોટો છે: application state બધા વપરાશકારો વચ્ચે વહેંચાયેલું છે, એટલે એ કોઈ એક ચોક્કસ વપરાશકારની ઓળખ રાખી શકે નહીં, બધા માટે એ એક જ કિંમત હોય. વપરાશકાર દીઠ અને ખાનગી હોય તો server બાજુનું session.
Think first
Cookie કે session: પસંદગી કઈ રીતે કરવી?
Cookie અને session બંને વપરાશકાર દીઠ કશુંક યાદ રાખી શકે છે. કયા સંજોગોમાં કયું વાપરવું? વિચારીને પછી tap કરો.
Show the answer
Data ક્યાં રહેવો જોઈએ અને એ કેટલો સંવેદનશીલ છે એના પરથી પસંદ કરો. COOKIE data ને browser માં સંઘરે છે, એટલે વપરાશકાર site બંધ કરીને પછીથી પાછો આવે તો પણ એ ટકી રહે છે (એની મુદત પૂરી ન થાય ત્યાં સુધી), અને એ server ની કશી memory વાપરતું નથી, પણ વપરાશકાર એને જોઈ અને બદલી શકે છે, એટલે એ 'મારો theme યાદ રાખો' કે 'remember me' જેવી નાની, બિનગુપ્ત પસંદગીઓ માટે યોગ્ય છે. SESSION data ને SERVER પર, એ વપરાશકારની ચાવી સાથે સંઘરે છે; browser પાસે ફક્ત નાનકડી session id હોય છે, એટલે ખરો data ખાનગી અને છેડછાડ સામે ટકાઉ રહે છે, અને એ મોટા તથા સમૃદ્ધ objects પણ સમાવી શકે છે, પણ એ server ની memory વાપરે છે અને સામાન્ય રીતે session ની મુદત પૂરી થાય કે વપરાશકાર જતો રહે ત્યાં સુધી જ ટકે છે. અંગૂઠાનો નિયમ: હાનિરહિત, નાનું અને મુલાકાતો વચ્ચે ટકવું જોઈએ તે cookie માં; ખાનગી, અગત્યનું કે મોટું અને ફક્ત આ મુલાકાત પૂરતું હોય તે session માં. ઘણી વાર બંને સાથે કામ કરે છે: session id પોતે cookie માં જ લઈ જવાય છે. Data ની સંવેદનશીલતા અને આવરદા પ્રમાણે રીત ગોઠવો.
Summary
Key takeaways
- HTTP stateless છે: દરેક request સ્વતંત્ર છે, એટલે apps requests વચ્ચે data યાદ રાખવા state management વાપરે છે.
- Client બાજુનું state browser માં કે URL માં ફરે છે: cookies (નાનો ટકાઉ data), query string (URL માંની કિંમતો), view state (postbacks દરમિયાન page ના controls ની કિંમતો).
- Server બાજુનું state server પર રહે છે: session (વપરાશકાર દીઠ) અને application (બધા વપરાશકારો વચ્ચે વહેંચાયેલું).
- Client બાજુ server ની memory વાપરતું નથી પણ દેખાય છે કે બદલી શકાય છે; ગુપ્ત વસ્તુઓ ત્યાં કદી ન મૂકો.
- Server બાજુ ખાનગી છે અને વધુ સમાવી શકે છે, પણ એની કિંમત server ની memory છે.
- વપરાશકારની ઓળખ માટે session વાપરો, નાની ટકાઉ પસંદગીઓ માટે cookie, અને query string ફક્ત બિનગુપ્ત કિંમતો માટે.
- યાદ રાખવાની કડી: cookies અને query string client પર રહે છે; session અને application server પર રહે છે.