HTTP 407 ឬ 401៖ តើការចូលណាមួយកំពុងបរាជ័យ?
បែងចែកការផ្ទៀងផ្ទាត់អត្តសញ្ញាណប្រូកស៊ីនិងគេហទំព័រ ពិនិត្យបឋមកថាត្រឹមត្រូវ ហើយកុំផ្ញើព័ត៌មានចូលទៅភាគីខុស។
407 ស្នើឱ្យផ្ទៀងផ្ទាត់អត្តសញ្ញាណជាមួយប្រូកស៊ី។ 401 ស្នើសម្រាប់ធនធានគោលដៅ។ សំណើមួយអាចជួបទាំងពីរ ដូច្នេះដឹងថាអ្នកណាកំពុងស្នើ មុនផ្តល់ពាក្យសម្ងាត់។
ប្រៀបធៀបស្ថានភាពនិងបឋមកថាស្នើការផ្ទៀងផ្ទាត់
| ចម្លើយ | បឋមកថាស្នើការផ្ទៀងផ្ទាត់ | បឋមកថាព័ត៌មានចូល | ភាគីពាក់ព័ន្ធ |
|---|---|---|---|
| 407 Proxy Authentication Required | Proxy-Authenticate | Proxy-Authorization | ប្រូកស៊ីកណ្តាល |
| 401 Unauthorized | WWW-Authenticate | Authorization | ដំណើរការផ្ទៀងផ្ទាត់របស់ធនធានដើម |
ស្ថានភាពជាតម្រុយដំបូងសំខាន់ ប៉ុន្តែពិនិត្យការផ្លាស់ប្តូរទាំងមូល។ លេខ 407 ក្នុងអត្ថបទទំព័រមិនស្មើនឹងចម្លើយ HTTP 407 ពិតទេ។ ដូចគ្នា ទំព័រចូលផ្ទាល់ខ្លួនអាចផ្តល់ 200 តែនៅតែទាមទារការផ្ទៀងផ្ទាត់នៅស្រទាប់កម្មវិធី។
ហេតុអ្វី HTTPS អាចបរាជ័យដោយ 407 មុនទៅដល់គេហទំព័រ?
ពេលប្រូកស៊ី HTTP ធម្មតាដឹកសំណើ HTTPS កម្មវិធីភ្ញៀវជាទូទៅស្នើបង្កើតផ្លូវរូង CONNECTជាមុន។ ប្រូកស៊ីអាចស្នើការផ្ទៀងផ្ទាត់សម្រាប់សំណើ CONNECT នោះ។ បើមិនទាន់បញ្ចប់ សម័យ TLS ជាមួយគោលដៅតាមផ្លូវរូងនៅមិនទាន់បង្កើតទេ។ ការប្តូរ API token របស់គេហទំព័រទំនងមិនជួសជុលដំណាក់កាលនេះទេ។
ប្រើលទ្ធផលលម្អិតដើម្បីមើលទីតាំងសំណើផ្ទៀងផ្ទាត់៖
curl --noproxy '' --proxy http://127.0.0.1:8080 --connect-timeout 5 --max-time 15 --verbose https://example.com/ជំនួសកម្មវិធីស្តាប់ក្នុងម៉ាស៊ីនដោយរបស់អ្នក ហើយអានសំណើផ្ទៀងផ្ទាត់ដំបូងក្នុងកំណត់ហេតុ។ 407 ក្នុង CONNECT មកមុន TLS គោលដៅ។ 401 ពេលក្រោយអាចមកបន្ទាប់ពីផ្លូវរូងបង្កើតបានជោគជ័យ។
ផ្តល់ព័ត៌មានប្រូកស៊ីតាមចំណុចប្រទាក់ប្រូកស៊ី
សម្រាប់ចំណុចចុងនិងគណនីដែលអ្នកគ្រប់គ្រងគួរឱ្យទុកចិត្តផ្តល់ឱ្យ curl អាចចរចាវិធីផ្ទៀងផ្ទាត់ប្រូកស៊ី ហើយសួរពាក្យសម្ងាត់ដែលមិនបានផ្តល់៖
curl --proxy http://proxy.example:8080 --proxy-anyauth --proxy-user alice https://example.com/ជំនួសចំណុចចុងនិងអ្នកប្រើក្នុងឧទាហរណ៍ដោយព័ត៌មានសេវាដែលអ្នកមានសិទ្ធិប្រើ។ បញ្ជាក់តែអ្នកប្រើដើម្បីជៀសវាងពាក្យសម្ងាត់ដោយផ្ទាល់ក្នុងពាក្យបញ្ជាខាងលើ។ វិធីដែលគាំទ្រអាចខុសតាមប៊ីលដ៍ curl និងប្រូកស៊ី។ បើចរចាបរាជ័យ ពិនិត្យសំណើពិតនិងសមត្ថភាពប៊ីលដ៍។
ជម្រើសផ្ទៀងផ្ទាត់ប្រូកស៊ីដាច់ពីជម្រើសអ្នកប្រើម៉ាស៊ីនមេដើមរបស់ curl។ កុំបន្ថែមបឋមកថា Authorization របស់ដើម ជំនួសការឆ្លើយសំណើប្រូកស៊ី។ ក៏កុំផ្ញើបឋមកថាព័ត៌មានប្រូកស៊ីដោយដៃទៅសំណើមិនពាក់ព័ន្ធ ឬរក្សាទុកក្នុងបឋមកថាប្រើឡើងវិញទូទាំងកម្មវិធី។
បើប្រូកស៊ីបន្តផ្តល់ 407
- បញ្ជាក់ថាអ្នកប្រើឈ្មោះម៉ាស៊ីននិងច្រកប្រូកស៊ីដែលចង់បាន។
- ពិនិត្យវិធីដែលប្រូកស៊ីប្រកាស ជាជាងសន្មត Basic។
- បញ្ជាក់ស្ថានភាពគណនីនិងទម្រង់ឈ្មោះអ្នកប្រើជាក់លាក់ដែលសេវាទាមទារ។
- ពិនិត្យការផ្ញើតួអក្សរពិសេស បើព័ត៌មាននៅក្នុង URL។
- កំណត់ថាការផ្ទៀងផ្ទាត់សហគ្រាសរួមជាមួយកម្មវិធីរុករកត្រូវការជំនួយពីបរិស្ថានដំណើរការឬវេទិកាឬអត់។
- បើភស្តុតាងកម្មវិធីភ្ញៀវមិនគ្រប់គ្រាន់ ស្នើអ្នកគ្រប់គ្រងផ្តល់លេខសម្គាល់សំណើឬកំណត់ហេតុម៉ាស៊ីនមេដែលបានដកព័ត៌មានរសើប។
403 ឬ CONNECT ដែលត្រូវបដិសេធអាចជាការសម្រេចតាមគោលការណ៍ចូលប្រើ ទោះចូលបានជោគជ័យក៏ដោយ។ ការសាកពាក្យសម្ងាត់បន្ថែមមិនផ្តល់សិទ្ធិចូលគោលដៅហាមឃាត់ទេ។
HTTPS គោលដៅមិនការពារគ្រប់ការផ្លាស់ប្តូរព័ត៌មានចូលប្រូកស៊ីទេ
ការផ្ទៀងផ្ទាត់ប្រូកស៊ីអាចកើតមុន TLS គោលដៅ។ បើការតភ្ជាប់ទៅប្រូកស៊ីផ្ទាល់មិនអ៊ិនគ្រីប ហើយវិធីបង្ហាញព័ត៌មានប្រើឡើងវិញលើតំណនោះ គោលដៅ HTTPS មិនការពារការផ្លាស់ប្តូរមុននោះក្រោយហេតុការណ៍ទេ។ ជ្រើសការដឹកជញ្ជូននិងការផ្ទៀងផ្ទាត់សមស្របនឹងសេវា។ កុំផ្ញើគណនីឯកជនទៅប្រូកស៊ីសាធារណៈមិនស្គាល់។
ពិនិត្យកំណត់ហេតុលម្អិតមុនចែករំលែក។ ទោះឧបករណ៍លាក់វាលព័ត៌មានចូលធម្មតា ក៏អាចនៅមានអ្នកប្រើ ឈ្មោះចំណុចចុងខាងក្នុង ខូគី ឬព័ត៌មានសម្គាល់ផ្សេង។