Theory
Logged In, फिर वापस एक Stranger
एक student event portal में login करता है। ये events page पर click करते हैं और: portal को कोई idea नहीं कि ये कौन हैं। फिर login कीजिए, फिर click कीजिए, फिर भूल जाइए।
यह आपके code में एक bug नहीं है; यह वह तरीका है जिससे web काम करता है। HTTP stateless है: हर request independent है, और server default से इनके बीच कुछ भी याद नहीं रखता। किसी को logged in रखने के लिए, आपको खुद memory add करनी पड़ती है। PHP आपको 2 tools देती है, cookies और sessions, और इनके बीच correctly choose करना एक security decision है जो यह lesson clear बनाता है।
At a glance
Cookies बनाम Sessions (Exam Contrast)
| Aspect | Cookie | Session |
|---|---|---|
| Stored कहाँ | BROWSER में (client) | SERVER पर |
| User देख/edit कर सकता है? | हाँ: visible, editable | नहीं: सिर्फ़ एक session ID cookie exposed है |
| Security | Lower: कभी sensitive data store मत कीजिए | Higher: data server-side रहता है |
| Lifetime | इसके expiry तक (days के लिए persist कर सकता है) | Logout या timeout तक |
| इसके लिए अच्छा | Preferences remember करना, 'remember me' | Login state, cart, private data |
Theory
हर एक कैसे काम करता है
Cookies data के छोटे pieces हैं जो BROWSER में stored होते हैं और हर request के साथ वापस भेजे जाते हैं। एक set कीजिए setcookie("theme", "dark", time() + 86400); से (1 day में expire होता है) और इसे $_COOKIE["theme"] से पढ़िए। चूँकि user cookies देख और edit कर सकता है, इनमें कभी sensitive data store मत कीजिए।
Sessions data SERVER पर store करती हैं, एक session ID से keyed जिसे PHP एक cookie में रखता है। session को इस्तेमाल करने वाले हर page के TOP पर session_start() call कीजिए (किसी भी output से पहले), फिर $_SESSION["user"] पढ़िए/लिखिए। Actual data कभी server नहीं छोड़ता, तो login state यहीं belong करता है। Logout पर session_destroy() से इसे end कीजिए।
Practical
Login एक Session में Stored, एक दूसरे Page पर Checked
<?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 से confirm करता है। PHP का basic tool है:
mail($to, $subject, $message, $headers);
$headers string extras set करती है: From:, और अगर आपको एक HTML email चाहिए तो Content-Type: text/html। एक honest caveat जिसे exam शायद stress न करे पर reality करती है: mail() को actually deliver करने के लिए एक properly configured mail server चाहिए, यही वजह है production apps usually एक library और SMTP इस्तेमाल करती हैं (जैसे Grishu platform खुद करता है)। इस syllabus के लिए, mail() signature जानिए और हर argument क्या करता है: recipient, subject, body, headers।
Quiz
Portal को यह fact कहाँ store करना चाहिए कि एक user logged in है: एक cookie या एक session, और क्यों?
- एक cookie, क्योंकि यह browser में stored है और faster है
- एक session, क्योंकि login state sensitive है और sessions data SERVER पर रखते हैं जहाँ user इसे देख या edit नहीं कर सकता
- दोनों equally secure हैं
- कोई नहीं: HTTP logins automatically याद रखता है
Show the answer
एक session, क्योंकि login state sensitive है और sessions data SERVER पर रखते हैं जहाँ user इसे देख या edit नहीं कर सकता
Login state sensitive है, तो यह एक SESSION में belong करता है, जो data को SERVER पर store करता है; सिर्फ़ एक session ID एक cookie में travel करता है, और user actual login data पढ़ नहीं सकता या इसके साथ tamper नहीं कर सकता। एक COOKIE अपना data browser में store करता है जहाँ user इसे view और EDIT कर सकता है, तो 'logged_in = true' को एक raw cookie में डालना किसी को भी logged in होने की faking करने देता: एक serious hole। Option A ग़लत चीज़ को prioritise करता है (security के ऊपर speed)। Option C ignore करता है हर एक data कहाँ store करता है। Option D false है: HTTP stateless है और कुछ याद नहीं रखता। Rule: private state (logins) के लिए sessions, non-sensitive preferences के लिए cookies।
Think first
Headers-Already-Sent Error
एक student कुछ HTML पहले से echo करने के बाद session_start() call करता है, और एक 'headers already sent' warning पाता है। session_start() first क्यों आना पड़ता है? फिर tap कीजिए।
Show the answer
session_start() (setcookie और दूसरे header operations की तरह) एक HTTP HEADER भेजता है: session ID cookie: और HTTP को सारे headers किसी भी body content (HTML) से PEHLE भेजे जाने चाहिए। एक बार जब आप even एक character भी echo करते हैं, PHP ने body शुरू कर दी है और headers flush कर दिए हैं, तो एक बाद वाला session_start() अपना header add नहीं कर सकता, इसलिए 'headers already sent'। Fix: page के बिल्कुल TOP पर session_start() call कीजिए, किसी भी echo से पहले, किसी भी HTML से पहले, यहाँ तक कि <?php से पहले किसी stray whitespace से भी पहले। यह ordering rule (output से पहले headers) सबसे common PHP errors में से एक है और एक frequent exam point है। session_start() को हमेशा first रखिए।
Watch out
State और Email Traps
Cookies में Sensitive Data: users cookies पढ़/edit कर सकते हैं; login state एक SESSION में जाता है।
Output के बाद session_start(): यह किसी भी output से पहले आना ज़रूरी है (यहाँ तक कि <?php से पहले whitespace भी), वरना 'headers already sent'।
एक Page पर session_start() भूलना: उन pages पर $_SESSION empty है जो session start नहीं करते।
mail() को हमेशा Deliver करने के लिए Trust करना: इसे एक configured mail server चाहिए; production SMTP libraries इस्तेमाल करता है।
Logout पर session_destroy() Call न करना: session को alive छोड़ता है।
Theory
Portal के पास Memory है; अब Structure
Sessions के साथ, portal आपको pages के across logged in रखता है और आपका confirmation email करता है: यह आख़िरकार एक real application जैसा feel होता है। एक Unit 2 lesson बाकी है: code को PHP की object-oriented features (classes, inheritance, visibility) और try/catch/finally के साथ robust error handling, plus regex validation से proper STRUCTURE देना। फिर Unit 3 portal को एक real MySQL database से जोड़ता है। Memory add हो गई; organisation अगला है।
Summary
Key takeaways
- HTTP stateless है: server requests के बीच आपको भूल जाता है, तो आपको खुद memory add करनी पड़ती है।
- Cookies data को BROWSER में store करती हैं (user के लिए visible/editable): सिर्फ़ non-sensitive data के लिए; setcookie से set कीजिए, $_COOKIE से पढ़िए।
- Sessions data को SERVER पर store करती हैं (एक session ID cookie से keyed): किसी भी output से पहले session_start() call कीजिए, $_SESSION इस्तेमाल कीजिए।
- Login state sensitive है: इसे एक SESSION में store कीजिए, कभी एक raw cookie में नहीं।
- session_start() (और setcookie) headers भेजते हैं, तो ये किसी भी OUTPUT से पहले आने चाहिए (वरना 'headers already sent')।
- mail($to, $subject, $message, $headers) email भेजता है; real delivery के लिए एक configured mail server/SMTP चाहिए।
- Memory hook: browser में cookie, server पर session, session_start() first।