Theory
Log in થયા, પછી ફરી અજાણ્યા
એક વિદ્યાર્થી event portal માં log in કરે છે. એ events ના page પર click કરે છે અને પછી portal ને એ કોણ છે એની કશી ખબર જ નથી. ફરી log in કરો, ફરી click કરો, ફરી ભુલાઈ જાઓ.
આ તમારા code ની ભૂલ નથી; વેબ આ જ રીતે કામ કરે છે. HTTP stateless છે: દરેક request સ્વતંત્ર છે, અને મૂળભૂત રીતે server એમની વચ્ચે કશું યાદ રાખતું નથી. કોઈને log in રાખવો હોય તો યાદશક્તિ તમારે જ ઉમેરવી પડે. PHP તમને 2 ઓજાર આપે છે, cookies અને sessions, અને એ બેમાંથી સાચું પસંદ કરવું એ સલામતીનો નિર્ણય છે જેને આ પાઠ સ્પષ્ટ કરે છે.
At a glance
Cookies સામે sessions (પરીક્ષાની સરખામણી)
| બાબત | Cookie | Session |
|---|---|---|
| ક્યાં સંઘરાય છે | BROWSER માં (client પર) | SERVER પર |
| વપરાશકાર જોઈ કે બદલી શકે? | હા: દેખાય છે, બદલી શકાય છે | ના: ફક્ત session ID વાળી cookie જ ખુલ્લી હોય છે |
| સલામતી | ઓછી: સંવેદનશીલ data કદી ન સંઘરો | વધુ: data server પર જ રહે છે |
| આવરદા | એની મુદત પૂરી થાય ત્યાં સુધી (દિવસો સુધી ટકી શકે) | Logout કે મુદત પૂરી થાય ત્યાં સુધી |
| કયા માટે સારું | પસંદગીઓ યાદ રાખવી, 'remember me' | Login ની સ્થિતિ, cart, ખાનગી data |
Theory
બંને કઈ રીતે કામ કરે છે
Cookies એ browser માં સંઘરાયેલા data ના નાના ટુકડા છે જે દરેક request સાથે પાછા મોકલાય છે. એને setcookie("theme", "dark", time() + 86400); થી ગોઠવો (1 દિવસમાં મુદત પૂરી) અને $_COOKIE["theme"] થી વાંચો. વપરાશકાર cookies જોઈ અને બદલી શકે છે, એટલે એમાં સંવેદનશીલ data કદી ન સંઘરો.
Sessions data ને SERVER પર સંઘરે છે, અને એની ચાવી તરીકે PHP એક session ID cookie માં રાખે છે. Session વાપરતા દરેક page ની ટોચે (કોઈ પણ output પહેલાં) session_start() બોલાવો, પછી $_SESSION["user"] વાંચો કે લખો. ખરો data server ની બહાર કદી જતો નથી, એટલે login ની સ્થિતિ અહીં જ રહેવી જોઈએ. Logout વખતે session_destroy() થી એને પૂરું કરો.
Practical
Session માં સચવાયેલું login, બીજા page પર તપાસાયેલું
<?php
// login.php (after validating credentials)
session_start(); // before any output
$_SESSION["user"] = "Riya"; // stored on the SERVER
// Send a confirmation email
$to = "riya@example.com";
$subject = "Registration confirmed";
$message = "Welcome to the Event Portal, Riya!";
$headers = "From: portal@example.com\r\n";
mail($to, $subject, $message, $headers);
?>
<?php
// events.php (a different page)
session_start();
if (isset($_SESSION["user"])) {
echo "Welcome back, " . $_SESSION["user"]; // Welcome back, Riya
} else {
echo "Please log in";
}
?>
Theory
mail() થી email મોકલવું
Portal registration ની ખાતરી email થી આપે છે. PHP નું પાયાનું ઓજાર છે:
mail($to, $subject, $message, $headers);
$headers નો string વધારાની વિગતો ગોઠવે છે: From:, અને HTML વાળું email જોઈતું હોય તો Content-Type: text/html. પરીક્ષા કદાચ ભાર ન મૂકે પણ વાસ્તવિકતા મૂકે છે એવી એક પ્રામાણિક ચેતવણી: ખરેખર પહોંચાડવા માટે mail() ને બરાબર ગોઠવાયેલો mail server જોઈએ, અને એટલે જ production ની apps સામાન્ય રીતે કોઈ library અને SMTP વાપરે છે (જેમ Grishu platform પોતે વાપરે છે). આ અભ્યાસક્રમ માટે mail() નું રૂપ અને દરેક argument શું કરે છે તે જાણો: મેળવનાર, વિષય, સંદેશો, headers.
Quiz
વપરાશકાર log in થયેલો છે એ હકીકત portal ક્યાં સંઘરે: cookie માં કે session માં, અને શા માટે?
- Cookie માં, કારણ કે એ browser માં સંઘરાય છે અને વધુ ઝડપી છે
- Session માં, કારણ કે login ની સ્થિતિ સંવેદનશીલ છે અને sessions data ને SERVER પર રાખે છે જ્યાં વપરાશકાર એને જોઈ કે બદલી શકતો નથી
- બંને એકસરખાં સલામત છે
- એકેયમાં નહીં: HTTP logins આપોઆપ યાદ રાખે છે
Show the answer
Session માં, કારણ કે login ની સ્થિતિ સંવેદનશીલ છે અને sessions data ને SERVER પર રાખે છે જ્યાં વપરાશકાર એને જોઈ કે બદલી શકતો નથી
Login ની સ્થિતિ સંવેદનશીલ છે, એટલે એ SESSION માં જ રહેવી જોઈએ, જે data ને SERVER પર સંઘરે છે; cookie માં ફક્ત session ID જ મુસાફરી કરે છે, અને વપરાશકાર ખરો login નો data વાંચી કે એમાં છેડછાડ કરી શકતો નથી. COOKIE પોતાનો data browser માં સંઘરે છે જ્યાં વપરાશકાર એને જોઈ અને બદલી શકે છે, એટલે કાચી cookie માં 'logged_in = true' મૂકવાથી કોઈ પણ log in થયેલા હોવાનો ડોળ કરી શકે: એ ગંભીર બાકોરું છે. વિકલ્પ A ખોટી વસ્તુને પ્રાધાન્ય આપે છે (સલામતી કરતાં ઝડપને). વિકલ્પ C બંને ક્યાં data સંઘરે છે એ અવગણે છે. વિકલ્પ D ખોટો છે: HTTP stateless છે અને કશું યાદ રાખતું નથી. નિયમ: ખાનગી સ્થિતિ (logins) માટે sessions, બિનસંવેદનશીલ પસંદગીઓ માટે cookies.
Think first
'headers already sent' વાળી ભૂલ
એક વિદ્યાર્થી થોડું HTML echo કરી લીધા પછી session_start() બોલાવે છે, અને એને 'headers already sent' ની ચેતવણી મળે છે. session_start() પહેલાં જ કેમ આવવું જોઈએ? વિચારીને પછી tap કરો.
Show the answer
session_start() (setcookie અને બીજી header ની ક્રિયાઓની જેમ) એક HTTP header મોકલે છે, એટલે કે session ID વાળી cookie, અને HTTP માટે બધા headers શરીરની કોઈ પણ સામગ્રી (HTML) પહેલાં જ મોકલાવા જોઈએ. તમે એક પણ અક્ષર echo કરો એટલે PHP એ શરીર શરૂ કરી દીધું અને headers મોકલી દીધા, એટલે પછીનું session_start() પોતાનું header ઉમેરી શકતું નથી, અને એટલે જ 'headers already sent' આવે છે. ઉપાય: session_start() ને page ની સાવ ટોચે બોલાવો, કોઈ પણ echo, કોઈ પણ HTML, અને <?php પહેલાંની આડીઅવળી ખાલી જગ્યા પણ આવે એ પહેલાં. ક્રમનો આ નિયમ (output પહેલાં headers) PHP ની સૌથી સામાન્ય ભૂલોમાંનો એક છે અને પરીક્ષામાં વારંવાર પુછાય છે. session_start() હંમેશા સૌથી પહેલાં મૂકો.
Watch out
State અને email ના ફાંદા
Cookies માં સંવેદનશીલ data: વપરાશકારો cookies વાંચી અને બદલી શકે છે; login ની સ્થિતિ SESSION માં જ જાય.
Output પછી session_start(): એ કોઈ પણ output પહેલાં આવવું જ જોઈએ (<?php પહેલાંની ખાલી જગ્યા પણ ગણાય), નહીં તો 'headers already sent' આવે.
Page પર session_start() ભૂલી જવું: જે pages session શરૂ કરતાં નથી ત્યાં $_SESSION ખાલી હોય છે.
mail() હંમેશા પહોંચાડશે એવો ભરોસો: એને ગોઠવાયેલો mail server જોઈએ; production માં SMTP વાળી libraries વપરાય છે.
Logout વખતે session_destroy() ન બોલાવવું: એથી session જીવતું રહી જાય છે.
Theory
Portal ને યાદશક્તિ મળી; હવે માળખું
Sessions સાથે portal તમને pages વચ્ચે log in રાખે છે અને ખાતરીનું email મોકલે છે: છેવટે એ ખરી application જેવું લાગે છે. Unit 2 નો એક પાઠ બાકી છે: PHP નાં object-oriented લક્ષણો (classes, inheritance, visibility) અને try/catch/finally સાથે મજબૂત error handling થી code ને યોગ્ય માળખું આપવું, સાથે regex વાળી ચકાસણી પણ. પછી Unit 3 portal ને ખરા MySQL database સાથે જોડે છે. યાદશક્તિ ઉમેરાઈ; હવે ગોઠવણ.
Summary
Key takeaways
- HTTP stateless છે: server તમને requests વચ્ચે ભૂલી જાય છે, એટલે યાદશક્તિ તમારે ઉમેરવી પડે.
- Cookies data ને BROWSER માં સંઘરે છે (વપરાશકારને દેખાય અને બદલી શકાય): ફક્ત બિનસંવેદનશીલ data માટે વાપરો; setcookie થી ગોઠવો, $_COOKIE થી વાંચો.
- Sessions data ને SERVER પર સંઘરે છે (ચાવી તરીકે session ID વાળી cookie): કોઈ પણ output પહેલાં session_start() બોલાવો, અને $_SESSION વાપરો.
- Login ની સ્થિતિ સંવેદનશીલ છે: એને SESSION માં સંઘરો, કાચી cookie માં કદી નહીં.
- session_start() (અને setcookie) headers મોકલે છે, એટલે એ કોઈ પણ output પહેલાં આવવાં જોઈએ (નહીં તો 'headers already sent').
- mail($to, $subject, $message, $headers) email મોકલે છે; ખરેખર પહોંચાડવા ગોઠવાયેલો mail server કે SMTP જોઈએ.
- યાદ રાખવાની કડી: cookie browser માં, session server પર, અને session_start() સૌથી પહેલાં.