Cloudflare Turnstile ჩასვით? სერვერული შემოწმების გარეშე დაცვა არ მუშაობს

Cloudflare Turnstile-ის widget ფორმაზე ტოკენს ქმნის, მაგრამ ფორმის დაცვა მხოლოდ მაშინ სრულდება, როცა სერვერი ტოკენს Siteverify API-ით ამოწმებს და წარმატებული პასუხის შემდეგ ამუშავებს მოთხოვნას. Cloudflare-ის დაწყების ინსტრუქცია ბრაუზერში widget-ის ჩასმასა და სერვერულ გადამოწმებას დაყენების აუცილებელ ეტაპებად აღწერს. თუ შემოწმება მხოლოდ ბრაუზერში ხდება, ავტომატურ მოთხოვნას შეუძლია ფორმის გვერდი გამოტოვოს და მონაცემები პირდაპირ მიმღებ მისამართზე გაგზავნოს.

ამიტომ ფორმის ჩვეულებრივი გაგზავნაც და JavaScript-ით შესრულებული გაგზავნაც სერვერზე ერთსა და იმავე წესს უნდა დაექვემდებაროს: მიიღოს ტოკენი, გადაამოწმოს იგი და უარყოფითი პასუხისას შეწყვიტოს ფორმის ძირითადი მოქმედება. ეს წესი მოქმედებს მაშინაც, როცა widget მომხმარებელს გამართულად უჩანს.

შექმენით widget და ტოკენი ფორმას გააყოლეთ

Cloudflare-ის მართვის პანელში შექმენით Turnstile widget და მიუთითეთ დომენები, რომლებზეც მას გამოიყენებთ. მისგან მიღებული sitekey საჯაროა და გვერდზე იწერება; secret key მხოლოდ სერვერზე შეინახეთ, მაგალითად გარემოს ცვლადში. თუ secret key ბრაუზერში მოხვდება, მისი გამოყენება სხვასაც შეეძლება და ტოკენის შემოწმების სანდოობა დაიკარგება.

ფორმის გვერდზე ჩატვირთეთ Turnstile-ის api.js და ფორმის შიგნით განათავსეთ ელემენტი cf-turnstile კლასით; data-sitekey ატრიბუტში ჩაწერეთ თქვენი sitekey. ჩვეულებრივი HTML ფორმა ტოკენს cf-turnstile-response ველით აგზავნის. თუ მონაცემებს JavaScript-ით აგზავნით, დარწმუნდით, რომ ეს ველიც მოთხოვნაში ხვდება; დინამიკურად შექმნილ ფორმაზე კი widget-ის გამოჩენა და ტოკენის მიღება ცალ-ცალკე შეამოწმეთ.

განვითარების, სატესტო და სამუშაო გარემოებისთვის ცალკე widget-ები გამოიყენეთ, რათა მათი გასაღებები და დაშვებული დომენები ერთმანეთში არ აგერიოთ. Cloudflare-ის სატესტო sitekey-ით მიღებული ტოკენი სამუშაო secret key-ით არ დადასტურდება. გაშვებისას სერვერის კონფიგურაციაში სწორედ სამუშაო widget-ის შესაბამისი secret key უნდა იდოს.

როგორ უნდა გადაწყვიტოს სერვერმა, მიიღოს თუ არა ფორმა

Cloudflare-ის Siteverify-ის დოკუმენტაცია განსაზღვრავს POST მოთხოვნას მისამართზე https://challenges.cloudflare.com/turnstile/v0/siteverify: აუცილებელია secret და response ველები, ხოლო remoteip და idempotency_key არჩევითია. API პასუხს JSON ფორმატში აბრუნებს. ტოკენი შექმნიდან 300 წამს მოქმედებს და წარმატებით მხოლოდ ერთხელ მოწმდება.

1. ფორმის მიმღებმა სერვერმა წაიკითხოს cf-turnstile-response. თუ მნიშვნელობა აკლია ან მოსალოდნელი სტრიქონის ფორმა არ აქვს, მოთხოვნა უარყოს ფორმის მონაცემების დამუშავებამდე.
2. სერვერმა Siteverify-ს გაუგზავნოს საკუთარი secret მნიშვნელობა და მიღებული ტოკენი response ველში. remoteip დაამატეთ მხოლოდ მაშინ, როცა ვიზიტორის მისამართს სანდო გზით იღებთ; ტოკენის გადამოწმებისთვის ეს ველი სავალდებულო არ არის.
3. სერვერმა შეამოწმოს დაბრუნებული success. წარმატებული პასუხის შემთხვევაშიც შეადაროს hostname მოსალოდნელ დომენს და, თუ widget-ს action აქვს მინიჭებული, გადაამოწმოს ეს მნიშვნელობაც.
4. მხოლოდ ამ შემოწმებების შემდეგ შესრულდეს ფორმის მიზანი, მაგალითად შეტყობინების გაგზავნა ან ანგარიშის შექმნა. უარყოფითი პასუხის, გაუგებარი პასუხის ან Siteverify-სთან კავშირის შეცდომისას ეს მოქმედება არ შესრულდეს.

ეს მოთხოვნა–პასუხის სქემა კონკრეტულ framework-ზე არ არის დამოკიდებული. სერვერს შეუძლია ველების საკუთარი ვალიდაციაც ჩაატაროს, მაგრამ ტოკენის პასუხი უნდა მიიღოს მანამდე, სანამ მონაცემებს შეინახავს ან სხვა სერვისს გადაუგზავნის. ქსელური შეფერხების შემდეგ იმავე შემოწმების გამეორებისთვის Siteverify-ის არჩევითი idempotency_key გამოიყენება; ჩვეულებრივი განმეორებითი გაგზავნისთვის მომხმარებელს ახალი ტოკენი დასჭირდება.

Hostname-ის შეზღუდვა და ვადაგასული ტოკენი

Widget-ის კონფიგურაციაში დაუშვით მხოლოდ ის დომენები, რომლებსაც მართავთ. ამას სერვერზე პასუხის შემოწმებაც დაუმატეთ: Siteverify-ის დაბრუნებული hostname უნდა ემთხვეოდეს იმ დომენს, რომელზეც კონკრეტული ფორმაა განთავსებული. თუ ერთი სერვერი სხვადასხვა დომენიდან იღებს ფორმებს, თითოეულ მარშრუტს თავისი დაშვებული hostname-ები წინასწარ განუსაზღვრეთ; მხოლოდ success მნიშვნელობაზე დაყრდნობა ამ განსხვავებას ვერ გაითვალისწინებს.

ვადის საკითხი განსაკუთრებით იგრძნობა ფორმაზე, რომლის შევსებაც დიდხანს გრძელდება. ვადაგასული ან უკვე გამოყენებული ტოკენით გაგზავნა არ დაამუშავოთ; მომხმარებელს ახალი ტოკენის მიღებისა და ხელახლა გაგზავნის საშუალება მიეცით. ბრაუზერში widget-ის განახლება turnstile.reset ფუნქციით შეიძლება. თუ შესაძლებელია, უკვე შეყვანილი ფორმის ველები შეინარჩუნეთ, რათა დადასტურების გამეორებამ მთელი ფორმის თავიდან შევსება არ მოითხოვოს.

Siteverify-ის შეცდომები და შესაბამისი რეაქცია

Siteverify-ის error-codes ველი სერვერულ დიაგნოსტიკაში გამოიყენეთ. მომხმარებელს მოკლე, გასაგები შეტყობინება აჩვენეთ, ხოლო გასაღებისა და მოთხოვნის ფორმატის პრობლემები სერვერის მხარეს გამოასწორეთ:

• missing-input-response — response ველი არ გაიგზავნა. გადაამოწმეთ, მოჰყვა თუ არა ფორმას cf-turnstile-response; მომხმარებელს ხელახალი გაგზავნა მხოლოდ გამართული widget-ით შესთავაზეთ.
• invalid-input-response — ტოკენი არასწორია, დაზიანებულია ან ვადაგასულია. ფორმის მოქმედება შეწყვიტეთ და ახალი ტოკენი მოითხოვეთ.
• timeout-or-duplicate — ტოკენი ვადაგასულია ან უკვე გამოყენებულია. იმავე მნიშვნელობის ხელახლა გაგზავნა პრობლემას ვერ მოაგვარებს; განაახლეთ widget.
• missing-input-secret ან invalid-input-secret — secret აკლია ან არასწორია. შეამოწმეთ სერვერის კონფიგურაცია და მისი შესაბამისობა widget-თან.
• bad-request — Siteverify-მ არასწორად შედგენილი მოთხოვნა მიიღო. შეამოწმეთ გაგზავნილი ველებისა და მოთხოვნის ფორმატი.
• internal-error — შემოწმების სერვერული შეცდომაა. მოთხოვნის გამეორება შესაძლებელია, მაგრამ წარმატებული პასუხის მიღებამდე ფორმის ძირითადი მოქმედება არ შეასრულოთ.

Siteverify-სთან კავშირის დაკარგვას შესაძლოა საერთოდ არ მოჰყვეს error-codes ველი. ასეთ შემთხვევაშიც ფორმა წარმატებით მიღებულად არ მონიშნოთ; სერვერულ ჟურნალში ჩაიწერეთ შეცდომის სახეობა ისე, რომ secret key ჩანაწერში არ მოხვდეს.

ფორმის მისამართზე rate limiting ცალკე ჩართეთ

Cloudflare-ის ფორმების დაცვის გზამკვლევი პირდაპირ POST მოთხოვნებთან გასამკლავებლად ფორმის მიმღებ მისამართზე rate limiting-ს დამატებით ზომად აღწერს. Turnstile-ის ჩასმა ამ წესს ავტომატურად არ ქმნის. თუ ფორმის ტრაფიკი Cloudflare-ის ქსელში გადის, შეზღუდვა კონკრეტულ მარშრუტსა და POST მეთოდს მოარგეთ; სხვა შემთხვევაში ის სერვერზე ან მოთხოვნების მიმღებ ინფრასტრუქტურაში მოაწყვეთ.

ზღვარი ფორმის ჩვეულებრივ დატვირთვას დაუკავშირეთ. მეტისმეტად მკაცრმა წესმა შეიძლება რეალური მომხმარებლის განმეორებითი გაგზავნაც შეაფერხოს, მაგალითად მაშინ, როცა მან ვადაგასული ტოკენის შემდეგ ისევ სცადა ფორმის გაგზავნა. დააკვირდით როგორც დაბლოკილ მოთხოვნებს, ისე წარმატებულ გაგზავნებს და საჭიროებისამებრ შეცვალეთ ზღვარი. Turnstile-ს საიტის Cloudflare-ის ქსელში გატარება არ სჭირდება, მაგრამ Cloudflare-ის ქსელური rate limiting მხოლოდ იმ მოთხოვნებზე იმოქმედებს, რომლებიც ამ ქსელს გადის.

სამუშაო გარემოში გაშვების სია

• გააგზავნეთ ფორმა ტოკენის გარეშე და გადაამოწმეთ, რომ შეტყობინება არ იგზავნება და ანგარიში არ იქმნება.
• სწორი ტოკენის მიღების შემდეგ სცადეთ მისი ხელახლა გამოყენება; განმეორებით გაგზავნას ახალი ტოკენი უნდა დასჭირდეს.
• შეამოწმეთ, რომ სერვერი სამუშაო sitekey-ის შესაბამის secret key-ს იყენებს და სხვა hostname-ით მიღებულ წარმატებულ პასუხს უარყოფს.
• ვადაგასული ტოკენის შემდეგ widget განაახლეთ და გადაამოწმეთ, რომ მომხმარებელს ფორმის უკვე შეყვანილი მონაცემები არ ეკარგება.
• გადაამოწმეთ Siteverify-ის უარყოფითი და ქსელური შეცდომების დამუშავება, შემდეგ კი ფორმის მარშრუტზე rate limiting-ის მოქმედება და სერვერული ჟურნალების უსაფრთხოება.

ასევე წაიკითხეთ:

• GITA-ს გრანტზე განაცხადი: რეგისტრაციის გარეშე გაგზავნა შეუძლებელია
• Cloudflare Workers თუ Vercel: დაბალი ფასი მიგრაციას მარტივს არ ხდის