Theory
दो computers आपकी website चलाते हैं
जब एक student FestConnect पर register करता है, दो बहुत अलग machines शामिल होती हैं। उनका phone (client) form दिखाता है और उनके type करते ही react करता है। College का server असल में registration store करता है और इसे seat count के against check करता है।
Code कहीं भी चल सकता है, और यह matter करता है कहाँ। Browser में एक script type करते ही तुरंत 'email ग़लत लगता है' flash कर सकती है। Server पर एक script record save करके एक ticket email कर सकती है। कोई भी दूसरे का काम अच्छे से नहीं कर सकता।
Theory
Waiter और kitchen
एक restaurant में, waiter (client-side) वहीं है: आपका order लेता है, obvious mistakes ठीक करता है ('वह ख़त्म हो गया है'), instant responses देता है। Kitchen (server-side) नज़र से बाहर है: यह ingredients रखती है, secret recipes follow करती है, और असल में खाना बनाती है। आप एक customer को kitchen में नहीं जाने देंगे, और waiter cook नहीं कर सकता। एक website काम को बिल्कुल इसी तरह split करती है।
Theory
Client-side बनाम server-side
- Client-side scripting browser में चलती है। Language है JavaScript। यह clicks और keystrokes पर react करती है, बिना reload page update करती है, और तुरंत validate करती है। User इसे देख सकता है (View Source) और यहाँ तक कि switch off भी कर सकता है।
- Server-side scripting page भेजे जाने से पहले web server पर चलती है। Languages में शामिल हैं PHP, Python, Node। यह database पढ़ती और लिखती है, passwords check करती है, secrets रखती है, और HTML बनाती है। User इस code को कभी नहीं देखता।
असली sites दोनों इस्तेमाल करती हैं।
At a glance
काम कहाँ होता है
| Aspect | Client-side (JS) | Server-side (PHP/Python) |
|---|---|---|
| चलता है | browser पर | web server पर |
| इसमें अच्छा | instant UI, reactions | database, secrets, auth |
| User को visible? | हाँ (View Source) | नहीं |
| Reload चाहिए? | नहीं | आमतौर पर एक नई page return करता है |
Think first
Seats कौन check करता है?
FestConnect 'seats left: 3' दिखाता है। जो check एक 4th व्यक्ति को register होने से रोकता है वह browser (JS) में होना चाहिए या server पर, और इसे अकेले browser पर क्यों trust नहीं किया जा सकता?
Show the answer
Server पर। 'seats left' की browser copy stale हो सकती है (किसी और ने अभी register किया) और user JavaScript edit या disable कर सकता है। सिर्फ़ server असली, current database देखता है और 4th registration को reliably reject कर सकता है। Browser एक अच्छे experience के लिए hint कर सकता है ('full लगता है'), पर server truth रखता है। यही golden rule है: कभी भी client को उस चीज़ के लिए trust मत कीजिए जो correct होनी ही चाहिए।
Quiz
आपका FestConnect form submit होने से पहले blank fields reject करने के लिए JavaScript इस्तेमाल करता है। क्या यह database में bad data रोकने के लिए काफ़ी है?
- नहीं: server को दोबारा validate करना ज़रूरी है, क्योंकि users client-side JS bypass कर सकते हैं
- हाँ: client-side validation database को पूरी तरह secure करता है
- हाँ, जब तक आप और JavaScript checks भी जोड़ें
- नहीं: JavaScript forms बिल्कुल validate ही नहीं कर सकता
Show the answer
नहीं: server को दोबारा validate करना ज़रूरी है, क्योंकि users client-side JS bypass कर सकते हैं
Client-side JS validation एक तेज़, friendly experience के लिए है, पर एक user JS disable कर सकता है या सीधे एक request भेज सकता है, इसे पूरी तरह bypass करते हुए, तो save करने से पहले server को दोबारा check करना ज़रूरी है (A)। ज़्यादा JS (C) एक ऐसे checker को fix नहीं करता जिसे off switch किया जा सके। JS ज़रूर validate कर सकता है (D ग़लत है); यह बस defence की last line नहीं है। Rule: UX के लिए client पर validate कीजिए, security के लिए server पर दोबारा validate कीजिए।
Watch out
Trust trap
सबसे बड़ा misconception: 'मेरा JavaScript इसे check करता है, तो यह safe है'। Browser में जो भी है वह user को visible और editable है। Passwords, prices, seat limits, permissions, सब server पर enforce होने चाहिए। Client-side scripting एक page कैसा feel होता है यह बेहतर बनाती है; server-side scripting तय करती है क्या true है।
Theory
आप server side से पहले ही मिल चुके हैं
BCA303 (Python + SQLite) का database काम और BCA105 का SQL server-side थे: code जो browser से दूर, data के बगल चलता है। यह पूरा Unit 3 दूसरा आधा है, client side, JavaScript में। आख़िर तक, FestConnect का form browser में validate करेगा (यह unit) और आप बिल्कुल समझेंगे असली save अभी भी server का ही क्यों है।
Summary
Key takeaways
- Client-side scripting (JavaScript) browser में चलती है: instant reactions, UI updates, कोई reload नहीं; user को visible और disableable।
- Server-side scripting (PHP, Python, Node) server पर चलती है: database, secrets, authentication; user से hidden।
- असली sites दोनों इस्तेमाल करती हैं: snappy feel के लिए JS, truth और storage के लिए server।
- Client-side validation सिर्फ़ convenience है; security के लिए server को दोबारा validate करना ज़रूरी है।
- जो चीज़ correct होनी ही चाहिए (seats, prices, passwords) उसके लिए client को कभी trust मत कीजिए।
- Memory hook: waiter (client) और kitchen (server)।