Cookie, Session និង State

មាតិកា

HTTP គ្មានការចងចាំ
Cookie៖ កំណត់ត្រាដែល Browser យកតាមខ្លួន
របៀបដែល Login ដំណើរការ
ការកំណត់ Cookie ដែលសំខាន់
Session ធៀបនឹង Token
localStorage៖ ការចងចាំដែលមានតែ Browser ប្រើ
Third-Party Cookie និងការតាមដាន
សាកល្បងដោយខ្លួនឯង

នេះជាការពិតមួយដែលធ្វើឲ្យមនុស្សភាគច្រើនភ្ញាក់ផ្អើល៖ HTTP គឺ stateless។ Request នីមួយៗត្រូវបានដោះស្រាយដោយឡែក ហាក់ដូចជា server មិនដែលឃើញអ្នកពីមុនសោះ។ Server មិនចាំថាអ្នកបាន load ទំព័រដើមកាលពីមួយវិនាទីមុន ឬថាអ្នកបាន login ឬថាមានអ្វីខ្លះនៅក្នុងកន្ត្រករបស់អ្នកទេ។

នោះគឺជាជម្រើសនៃការរចនាដោយចេតនា ហើយជាជម្រើសល្អផង។ Server ដែលមិនចាំបាច់ចងចាំអ្វីទាំងអស់រវាង request គឺសាមញ្ញ ហើយងាយស្រួលក្នុងការដំណើរការច្បាប់ចម្លងរបស់វាច្រើននៅក្បែរគ្នា — ច្បាប់ចម្លងណាមួយក៏អាចឆ្លើយ request ណាមួយបានដែរ។

ប៉ុន្តែ website ពិតៗច្បាស់ជា ចងចាំ អ្នកមែន។ អ្នក login ម្តង ហើយនៅតែ login ដដែល។ កន្ត្រករបស់អ្នកនៅដដែលពីទំព័រមួយទៅទំព័រមួយ។ ភាសាដែលអ្នកបានជ្រើសនៅជាប់។ ដូច្នេះ តើការចងចាំនោះមកពីណា?

ចម្លើយ៖ client ជាអ្នកយកវាតាមខ្លួន។ ជាមួយ request នីមួយៗ browser ផ្ញើការរំលឹកតូចមួយអំពីថាអ្នកជានរណា។ ការរំលឹកនោះគឺជា cookie។

Cookie គឺជាអត្ថបទតូចមួយ ដែល server ស្នើឲ្យ browser រក្សាទុក ហើយផ្ញើត្រឡប់មកវិញ។ វាដំណើរការជាមួយ header ពីរ។

Server កំណត់ cookie មួយនៅក្នុង response ដោយប្រើ Set-Cookie៖

HTTP/1.1 200 OK
Set-Cookie: lang=km

Browser រក្សាទុកវា ដោយដាក់ស្លាកថាវាមកពី site ណា។ ចាប់ពីពេលនោះតទៅ រាល់ request ទៅកាន់ site ដដែលនោះ នឹងយកវាទៅជាមួយដោយស្វ័យប្រវត្តិ នៅក្នុង header Cookie៖

GET /products HTTP/1.1
Host: shop.example.com
Cookie: lang=km

Server អានវា ហើយឆ្លើយតបជាភាសាខ្មែរ។ វានៅតែមិនចងចាំអ្នកទេ — គឺអ្នកជាអ្នករំលឹកវា។

រឿងមួយចំនួនដែលគួរសម្គាល់៖

Browser ធ្វើរឿងនេះ ដោយស្វ័យប្រវត្តិ។ កូដរបស់អ្នកមិនចាំបាច់ភ្ជាប់ cookie ទេ ពួកវាគ្រាន់តែទៅជាមួយរាល់ request ទៅកាន់ site នោះ។
Cookie ជាកម្មសិទ្ធិរបស់ site មួយ។ Cookie ពី shop.example.com មិនដែលត្រូវបានផ្ញើទៅ google.com ទេ។
ពួកវាតូច — ច្រើនបំផុតប្រហែល 4 KB ក្នុងមួយ — ដូច្នេះពួកវាសម្រាប់តម្លៃខ្លីៗ មិនមែនសម្រាប់ទិន្នន័យទេ។

ការ login គឺជាការប្រើប្រាស់ cookie ដ៏សំខាន់បំផុត។ នេះគឺជាលំហូរបុរាណ៖

 Browser                                    Server
   │  POST /login                             │
   │  email=dara@…&password=…  ────────────▶  │  checks the password,
   │                                          │  creates session "a8f3…"
   │                                          │  and remembers: a8f3… = Dara
   │  ◀────────────  302 Found                │
   │                 Location: /dashboard     │
   │                 Set-Cookie: session=a8f3…│
   │                                          │
   │  GET /dashboard                          │
   │  Cookie: session=a8f3…   ─────────────▶  │  looks up a8f3… → Dara
   │  ◀────────────  200 OK, "Hi Dara!"       │

អ្នកផ្ញើ email និង password របស់អ្នក តែម្តង ជាមួយ POST មួយ។
Server ពិនិត្យពួកវា។ បើត្រឹមត្រូវ វាបង្កើត session មួយ៖ ID វែង និងចៃដន្យ — មិនអាចស្មានបាន — ហើយរក្សាទុកកំណត់ត្រាមួយនៅក្នុង database ឬ memory របស់វាថា «ID នេះជារបស់ Dara»។
វាផ្ញើ ID នោះត្រឡប់មកវិញក្នុង Set-Cookie ហើយ redirect អ្នក។
រាល់ request បន្ទាប់ពីនោះ យក session cookie ទៅជាមួយ។ Server រកមើល ID នោះ ហើយដឹងថាជាអ្នក។ Password របស់អ្នកមិនដែលត្រូវបានផ្ញើម្តងទៀតទេ។
នៅពេលអ្នក log out server លុប session នោះ ហើយ ID នោះក្លាយជាគ្មានតម្លៃ។

នេះមានន័យថា session cookie គឺពិតជា ខ្លួនអ្នក តែម្តង។ អ្នកណាក៏ដោយដែលទទួលបានច្បាប់ចម្លងរបស់វា អាចប្រើ site នោះជាអ្នក ដោយមិនត្រូវការ password របស់អ្នកឡើយ។ ការការពារវា គឺជាប្រធានបទនៃផ្នែកបន្ទាប់។

Header Set-Cookie អាចមានការកំណត់បន្ថែមនៅខាងក្រោយតម្លៃ៖

Set-Cookie: session=a8f3…; Max-Age=604800; Path=/; Secure; HttpOnly; SameSite=Lax

ការកំណត់	អ្វីដែលវាធ្វើ
`Max-Age` / `Expires`	រក្សាវាទុករយៈពេលប៉ុន្មាន។ បើគ្មាន វានឹងត្រូវលុបនៅពេល browser បិទ
`Path` / `Domain`	URL ណាខ្លះដែលវាត្រូវបានផ្ញើទៅ
`Secure`	ផ្ញើវាតែតាម HTTPS ប៉ុណ្ណោះ មិនដែលតាម HTTP ធម្មតាទេ
`HttpOnly`	JavaScript នៅលើទំព័រមិនអាចអានវាបានទេ — មានតែ browser ទេដែលផ្ញើវា
`SameSite`	ថាតើត្រូវផ្ញើវាឬអត់ នៅពេល site ផ្សេង ធ្វើ request នោះ

ការកំណត់បីចុងក្រោយគឺជាការកំណត់សុវត្ថិភាព ហើយ login cookie គួរតែមានទាំងបី៖

Secure — ព្រោះដូចដែលជំពូកទី 4 បានបង្ហាញ អ្វីៗដែលផ្ញើតាម HTTP ធម្មតា អាចត្រូវបានគេអានតាមផ្លូវ។
HttpOnly — ដើម្បីថា បើអ្នកវាយប្រហារអាចដំណើរការ JavaScript ផ្ទាល់ខ្លួនរបស់គេនៅលើទំព័របាន វាក៏នៅតែមិនអាចអាន session របស់អ្នក ហើយផ្ញើវាទៅគេបានដែរ។
SameSite=Lax (លំនាំដើមនៅក្នុង browser សម័យថ្មី) — ដើម្បីថា បើ website ផ្សេងមួយលួចផ្ញើ request ទៅធនាគាររបស់អ្នក cookie ធនាគាររបស់អ្នកនឹងមិនទៅជាមួយទេ។ រឿងនេះទប់ស្កាត់ការវាយប្រហារមួយហៅថា CSRF — cross-site request forgery។

អ្នកនឹងរៀនការវាយប្រហារទាំងនេះឲ្យបានត្រឹមត្រូវនៅលើ track សន្តិសុខសាយប័រ។ សម្រាប់ពេលនេះ៖ cookie ដែលបញ្ជាក់ថានរណាម្នាក់ជានរណា ត្រូវតែជា Secure, HttpOnly និង SameSite។

5. Session ធៀបនឹង Token

វិធី session រក្សាព័ត៌មានសំខាន់ នៅលើ server៖ cookie គ្រាន់តែជា ID ដែលចង្អុលទៅវាប៉ុណ្ណោះ។ មានវិធីទូទៅទីពីរមួយទៀត ដែល client យក token មួយតាមខ្លួន ដែលមានព័ត៌មាននោះនៅក្នុងខ្លួនវាផ្ទាល់ ហើយត្រូវបាន server ចុះហត្ថលេខា (sign) ដូច្នេះវាមិនអាចក្លែងបន្លំបានទេ។

	Session cookie	Token (ឧ. JWT)
អ្វីដែល client កាន់	ID ចៃដន្យមួយ	ទិន្នន័យដែលបាន sign៖ អ្នកជានរណា រហូតដល់ពេលណា
ការពិតនៅទីណា	កន្លែងរក្សាទុក session របស់ server	នៅក្នុង token
របៀបដែលវាត្រូវបានផ្ញើ	Header `Cookie` ដោយស្វ័យប្រវត្តិ	ជាធម្មតា `Authorization: Bearer …` ដោយកូដរបស់អ្នក
ទូទៅនៅក្នុង	Website បែបប្រពៃណី	API, mobile app, single sign-on

Keycloak Crash Course នៅលើ website នេះ ត្រូវបានបង្កើតឡើងលើ token — JWT មួយដែលផ្ញើក្នុង header Authorization — ហើយជំពូក «Understanding the JWT» របស់វា បង្ហាញពីអ្វីដែលមាននៅខាងក្នុង។ វិធីទាំងពីរដោះស្រាយបញ្ហាដូចគ្នា៖ ការរំលឹក server ដែល stateless ថាអ្នកជានរណា នៅលើរាល់ request។

6. localStorage៖ ការចងចាំដែលមានតែ Browser ប្រើ

Browser ក៏ផ្តល់ឲ្យ JavaScript នូវកន្លែងមួយសម្រាប់រក្សាទុកទិន្នន័យសម្រាប់ site មួយដែរ៖ localStorage។ វាគឺជាបញ្ជី key និង value សាមញ្ញមួយ៖

localStorage.setItem("theme", "dark");
localStorage.getItem("theme"); // "dark"

ភាពខុសគ្នាធំពី cookie៖ localStorage មិនដែលត្រូវបានផ្ញើទៅ server ទេ។ វានៅក្នុង browser ហើយមានតែ JavaScript របស់ទំព័រប៉ុណ្ណោះដែលអាចអានវាបាន។ វាក៏ផ្ទុកបានច្រើនជាងផងដែរ — ពីរបី megabyte ក្នុងមួយ site។

នោះធ្វើឲ្យវាល្អសម្រាប់អ្វីៗដែលមានតែ browser ទេដែលខ្វល់៖ ចំណូលចិត្ត សេចក្តីព្រាងដែលអ្នកមិនទាន់បានផ្ញើ tab ណាដែលបានបើក។ Website នេះផ្ទាល់ប្រើវាដើម្បីចងចាំថាតើអ្នកបានជ្រើស light mode ឬ dark mode — ព្រោះគ្មាន server ដើម្បីចងចាំវាឲ្យអ្នកទេ។

អ្វីដែលវា មិន ល្អសម្រាប់ គឺអាថ៌កំបាំង (secret)។ JavaScript ណាមួយនៅលើទំព័រអាចអានវាបាន ដូច្នេះវាមិនមានការការពារដូច cookie HttpOnly ទេ។

(sessionStorage ដំណើរការដូចគ្នា ប៉ុន្តែភ្លេចអ្វីៗទាំងអស់នៅពេលអ្នកបិទ tab។)

ទំព័រមួយអាច load អ្វីៗពី site ផ្សេង៖ ពាណិជ្ជកម្មមួយ ប៊ូតុង «Like» មួយ analytics script មួយ វីដេអូដែលបង្កប់មួយ។ Request ទាំងនោះទៅកាន់ server របស់ site ផ្សេងនោះ — ហើយពួកវាអាចកំណត់ និងទទួល cookie របស់ site នោះ។ ទាំងនេះត្រូវបានហៅថា third-party cookie។

នេះគឺជាបញ្ហា។ ស្រមៃមើលក្រុមហ៊ុនពាណិជ្ជកម្មមួយ ដែលពាណិជ្ជកម្មរបស់វាលេចឡើងនៅលើគេហទំព័រព័ត៌មាន ហាងអនឡាញ និងគេហទំព័រទេសចរណ៍។ រាល់ពេលដែលអ្នកចូលមើលណាមួយក្នុងចំណោមពួកវា browser របស់អ្នកផ្ញើ request ទៅកាន់ក្រុមហ៊ុនពាណិជ្ជកម្មនោះ ជាមួយ cookie ដដែលរបស់ក្រុមហ៊ុននោះ។ ឥឡូវក្រុមហ៊ុនពាណិជ្ជកម្មអាចបង្កើតបញ្ជីនៃគ្រប់ site ដែលអ្នកបានចូលមើល — ដោយអ្នកមិនដែលចូលមើល site របស់ក្រុមហ៊ុនពាណិជ្ជកម្មនោះផ្ទាល់សោះ។

នោះហើយជាមូលហេតុដែល៖

Browser ដូចជា Safari និង Firefox block third-party cookie តាមលំនាំដើម ហើយ Chrome ក៏អនុញ្ញាតឲ្យអ្នក block ពួកវាដែរ។
ប្រទេសជាច្រើនឥឡូវមានច្បាប់ឯកជនភាព ហើយ site ជាច្រើនបង្ហាញ cookie banner ទាំងនោះ ដែលសុំការយល់ព្រម មុនពេលកំណត់ cookie ដែលមិនចាំបាច់។

Cookie ដែលធ្វើឲ្យ site មួយដំណើរការ — login របស់អ្នក កន្ត្រករបស់អ្នក — ត្រូវបានហៅថា essential (ចាំបាច់)។ នៅពេល banner មួយផ្តល់ជម្រើសឲ្យអ្នក ការបដិសេធ cookie ដែលនៅសល់ នឹងមិនធ្វើឲ្យ site ខូចទេ។

8. សាកល្បងដោយខ្លួនឯង

មើល cookie របស់អ្នក។ Login ចូល site មួយដែលអ្នកប្រើ បើក DevTools ហើយទៅកាន់ Application → Cookies (Chrome/Edge) ឬ Storage → Cookies (Firefox)។ រក cookie មួយដែលមានធីក HttpOnly និង Secure។ ឈ្មោះរបស់វាច្រើនតែមាន session, sid ឬ auth។ កុំចម្លងវាទៅកន្លែងណាឡើយ — ចាំថា វាគឺជាខ្លួនអ្នក។
មើល cookie ត្រូវបានកំណត់។ រត់ command ទាំងនេះជាមួយ curl។ -c រក្សាទុក cookie ទៅក្នុង file មួយ ហើយ -b ផ្ញើពួកវាត្រឡប់ទៅវិញ៖
```
curl -c cookies.txt "https://httpbin.org/cookies/set?lang=km"
cat cookies.txt
curl -b cookies.txt https://httpbin.org/cookies
rm cookies.txt
```
curl ទីពីរផ្ញើ header Cookie ហើយ httpbin បង្ហាញវាត្រឡប់មកអ្នកវិញ។ នោះគឺជាការងារ cookie ទាំងមូលរបស់ browser ដែលធ្វើដោយដៃ។
រក header Set-Cookie។ នៅក្នុង Network tab ធ្វើការ reload site ធំមួយ ហើយចុចលើ request ទីមួយ។ មើលក្រោម Response Headers រក set-cookie។ តើវាប្រើការកំណត់អ្វីខ្លះ?
ពិនិត្យការចងចាំរបស់ site នេះ។ នៅលើ website នេះ បើក Application → Local Storage ហើយប្តូររវាង light mode និង dark mode។ មើលតម្លៃ theme ផ្លាស់ប្តូរ។

ឥឡូវអ្នកដឹងហើយថា web ចងចាំអ្នកដោយរបៀបណា។ បន្ទាប់ គឺរបៀបដែលវាជៀសវាងការទាញយករបស់ដដែលពីរដង — អាថ៌កំបាំងនៅពីក្រោយ website ដែលលឿន។

Cookie, Session និង State

ទិញកាហ្វេជូនខ្ញុំ