Strapi-ის როლები, უფლებები და API ტოკენები: დაცვა

Strapi-ის ახალი ინსტალაცია ნაგულისხმევად დახურულია და ეს კარგი ამბავია: Public როლს დასაწყისში არცერთი უფლება არ აქვს, ამიტომ კონტენტის ახალი ტიპი ანონიმურ მოთხოვნებს პასუხობს 403 Forbidden-ით, სანამ სხვაგვარად არ გადაწყვეტ. საფრთხე ნაგულისხმევ პარამეტრებში არ არის. საფრთხე ისაა, რასაც ადამიანები აკეთებენ პარასკევს საღამოს, რომ ფრონტენდმა იმუშაოს: Public-ზე ყველა ნიშანს ავსებენ, ქმნიან Full access API ტოკენს და ბრაუზერის ბანდლში ათავსებენ, რეგისტრაციას ღიას ტოვებენ და ყველა რედაქტორს Super Admin როლს აძლევენ. ეს სახელმძღვანელო განიხილავს Strapi-ის ოთხ ცალკე უფლებათა სისტემას, იმას, თუ რას აკონტროლებს თითოეული, და იმ თანმიმდევრობას, რომლითაც ახალი ინსტალაცია უნდა დაიცვა. ყოველ ნაბიჯზე არის curl-ით შემოწმება, რომ დარწმუნდე, ცვლილებამ ზუსტად ის გააკეთა, რასაც ფიქრობ.

ტექსტი ეხება Strapi 5-ს, მიმდინარე მთავარ ვერსიას. მენიუს სახელები 5.x რელიზებს შორის ოდნავ იცვლება, ამიტომ სადაც წარწერას მნიშვნელობა აქვს, ის ისეა მოცემული, როგორც Settings-ში ჩანს; ზოგადი სქემა Strapi 4-ზეც მართებულია.

ოთხი განსხვავებული „მომხმარებელი“ Strapi-ში#

Strapi-ს ოთხი იდენტობა აქვს, რომლებსაც ყველას „მომხმარებელს“ ეძახიან, და შეცდომების უმეტესობა მათ აღრევას უკავშირდება. თითოეული სხვადასხვა ცხრილშია შენახული, სხვადასხვა ეკრანზე იმართება და აპლიკაციის სხვადასხვა ნაწილამდე აღწევს.

ადმინ მომხმარებლები შენი რედაქტორები და დეველოპერები არიან. ისინი ადმინ პანელში ელფოსტითა და პაროლით შედიან, ხოლო რისი გაკეთება შეუძლიათ იქ, ადმინ როლით განისაზღვრება. ამ შესვლით content API-ზე წვდომა არ აქვთ: ადმინ პანელი საკუთარ შიდა მარშრუტებს მიმართავს /admin-ის ქვეშ.

საბოლოო მომხმარებლები Users and Permissions პლაგინს ეკუთვნიან: ეს ადამიანები შენს საიტზე რეგისტრირდებიან, თუ ამის უფლებას მისცემ. ისინი User ტიპის ჩვეულებრივი ჩანაწერებია, ავტორიზდებიან მისამართზე /api/auth/local და JWT-ს იღებენ. მათი უფლებები Users and Permissions-ის როლიდან მოდის: ან Authenticated, ან შენ მიერ შექმნილი.

API ტოკენები პროგრამებისთვისაა, არა ადამიანებისთვის: სტატიკური საიტის გენერატორი აწყობისას, მობილური აპლიკაციის ბექენდი, სკრიპტი. ტოკენს საკუთარი უფლებების სია აქვს და იგზავნება Authorization ჰედერში.

ანონიმურ სტუმარს არავითარი მონაცემი არ აქვს. რასაც მას დართავ, მთელ ინტერნეტს ეძლევა, საძიებო რობოტებისა და სკრეიპერების ჩათვლით. Strapi ასეთ მოთხოვნას Public როლს მიაკუთვნებს.

ეს სურათი თუ თავში გექნება, კითხვების უმეტესობას „რატომ არ გამომდის...“ თავისით გასცემ პასუხს. API ტოკენი ადმინ პანელს ვერ გახსნის. ადმინის პაროლი /api-ზე არ მუშაობს. Public-ის უფლება ყველასთვის უფლებაა, დანარჩენი სამი სახის მონაცემის მფლობელების ჩათვლით, რადგან მათ შეუძლიათ უბრალოდ გამოტოვონ მონაცემები და Public როლად დამუშავდებიან.

Public როლი: დაიწყე ნულიდან#

გახსენი Settings და Users and Permissions plugin-ში აირჩიე Roles. ჩაშენებული როლი ორია: Public და Authenticated. კონტენტის ყოველი ტიპისთვის როლის რედაქტორი ხელმისაწვდომ მოქმედებებს ჩამოთვლის: find (სია), findOne (ერთი ჩანაწერი), create, update და delete. Single types-ს თავისი ნაკრები აქვს. კონტენტის ახალ ტიპს Public-ისთვის არაფერი აქვს მონიშნული.

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

• ბლოგისთვის ან სარეკლამო საიტისთვის ჩვეულებრივ საკმარისია find და findOne იმ ტიპებზე, რომლებსაც საჯარო გვერდები ნამდვილად აჩვენებს.
• Public-ისთვის ნუ ჩართავ create, update და delete-ს. თუ საკონტაქტო ფორმას ჩანაწერების შექმნა სჭირდება, მის წინ დადე პატარა სერვერული მარშრუტი ან serverless ფუნქცია, ან დაეთანხმე იმას, რომ ერთ კონკრეტულ ტიპში ნებისმიერს შეუძლია ჩაწერა, და ყველაფერს, რაც იქ მოხვდება, მტრულ შეყვანად მიიჩნევ.
• ნახე, რა არის კიდევ სიაში. Users and Permissions განყოფილებაში არის user.find, user.findOne, user.count და სხვა. თუ Public-ისთვის user.find-ს მონიშნავ, რეგისტრირებული მომხმარებლების სია მათი ელფოსტის მისამართებით ინტერნეტში გამოქვეყნდება.
• Upload განყოფილებაში სხვათა შორის არის upload.find, upload.findOne და upload.destroy. ფაილები, რომლებზეც შენი კონტენტი მიუთითებს, ჩვეულებრივი სტატიკური ფაილების სახით გაიცემა თავისი URL-იდან და ამ უფლებებს არ საჭიროებს, ხოლო საჯარო destroy კატასტროფა იქნებოდა.

Public-ს ასევე ნაგულისხმევად ჩართული აქვს auth მოქმედებების ნაკრები (შესვლა, რეგისტრაცია, პაროლის აღდგენა), რადგან მათ გარეშე შესვლის მარშრუტები არ იმუშავებდა. სწორედ ამიტომაა მნიშვნელოვანი შემდეგი თავი.

შეამოწმე, რაც გაქვს. მანქანიდან, რომელზეც ტოკენი არ არის, cms.example.com-ის ნაცვლად შენი ჰოსტით:

$ curl -i https://cms.example.com/api/articles$ curl -i https://cms.example.com/api/pages$ curl -i https://cms.example.com/api/users

კონტენტის ტიპი, რომელიც არ გაგიხსნია, უპასუხებს HTTP/1.1 403 Forbidden-ით და JSON სხეულით, სადაც error.name არის ForbiddenError. გახსნილი ტიპი უპასუხებს 200-ით და data მასივით. თუ 403-ის ნაცვლად 404 მოვიდა, მარშრუტი არ არსებობს: კონტენტის ტიპის მრავლობითი სახელი განსხვავდება იმისგან, რაც აკრიფე. ეს სახელი Content-Type Builder-ში ნაჩვენებია როგორც API ID (plural) და სწორედ ის არის გზის სეგმენტი /api/-ის შემდეგ.

რას ხედავს Public თვით ჩანაწერის გარდა

ჩანაწერთან ერთად კავშირების გრაფის რამდენი ნაწილი დაბრუნდება, ორი მოთხოვნის პარამეტრით განისაზღვრება. ნაგულისხმევად Strapi 5 მხოლოდ ჩანაწერის საკუთარ ველებს აბრუნებს; კავშირები, მედია და კომპონენტები ჩნდება მაშინ, როცა მოთხოვნა მათ populate-ით ითხოვს. მოთხოვნა ?populate=*-ით ყველაფრის ერთ დონეს ითხოვს. გამოყენებულ როლს უნდა ჰქონდეს დაკავშირებული ტიპის წაკითხვის უფლებაც, ამიტომ article-ის გახსნა author-ს თავისით არ ხსნის, მაგრამ ორივეს გახსნით ადვილად გამოააშკარავებ იმაზე მეტს, ვიდრე გინდოდა.

მეორე პარამეტრი გვერდებად დაყოფაა. თუ არაფერს შეცვლი, კლიენტს შეუძლია გვერდის ნებისმიერი ზომა მოითხოვოს. შეზღუდე ის config/api.js-ში:

module.exports = {  rest: {    defaultLimit: 25,    maxLimit: 100,    withCount: true,  },};

defaultLimit მოქმედებს მაშინ, როცა მოთხოვნა ზომას არ ასახელებს, ხოლო maxLimit ჭერია, რომელსაც მოთხოვნა ვერ გადალახავს. პატარა maxLimit მომთმენ სკრეიპერს ვერ შეაჩერებს, მაგრამ მთელი ცხრილის ერთი მოთხოვნით გადმოწერას გამორიცხავს. თუ GraphQL პლაგინს იყენებ, მას ანალოგიური პარამეტრები აქვს (defaultLimit, maxLimit, depthLimit, amountLimit) config/plugins.js-ში, ხოლო Apollo-ს სანდბოქსს playgroundAlways მართავს; პროდაქშენში ის გამორთული დატოვე.

Authenticated როლი და რეგისტრაცია#

Authenticated როლს შესული საბოლოო მომხმარებელი იღებს. ისიც თითქმის ცარიელი იწყება. უმეტესი საიტისთვის საკითხი ის არ არის, რისი გაკეთება შეუძლია Authenticated-ს, არამედ ის, უნდა შეეძლოს თუ არა ვინმეს საერთოდ მისი გახდომა.

თუ შენს საიტზე წევრთა განყოფილება არ არის, პასუხია არა და ამისთვის ერთი გადამრთველი საკმარისია. Users and Permissions plugin-ში გახსენი Advanced settings და გამორთე Enable sign-ups. როცა ის გამორთულია, POST /api/auth/local/register ანგარიშებს აღარ ქმნის. იქვე გადახედე იმავე გვერდის დანარჩენ პარამეტრებსაც:

ელფოსტის დადასტურებას მუშა საფოსტო პროვაიდერი სჭირდება, ამიტომ ნუ ჩართავ მას, სანამ სატესტო წერილს არ გააგზავნი, თორემ ახალი მომხმარებლები საკუთარი ანგარიშებიდან გარეთ დარჩებიან. Strapi-ის ნაგულისხმევი პროვაიდერი, sendmail, ვარაუდობს, რომ მანქანაზე საფოსტო აგენტია, რაც პატარა კონტეინერში ჩვეულებრივ არ არის.

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

JWT-ს, რომელსაც Users and Permissions გასცემს, აქვს სიცოცხლის ხანგრძლივობა და ხელმოწერის საიდუმლო. საიდუმლო jwtSecret-ია, რომელიც დაგენერირებულ პროექტში JWT_SECRET-იდან იკითხება. ხანგრძლივობა jwt.expiresIn-ია config/plugins.js-ში და ნაგულისხმევი მნიშვნელობა გრძელია (წერის დროისთვის 30 დღე). ჰობი-საიტზე მეტი რამისთვის შეამოკლე:

module.exports = ({ env }) => ({  'users-permissions': {    config: {      jwtSecret: env('JWT_SECRET'),      jwt: {        expiresIn: '7d',      },    },  },});

JWT-ები სერვერზე არ ინახება, ამიტომ აქტიური სესიების სია, რომლის გაუქმებაც შეიძლებოდა, არ არსებობს. რისკს ამცირებს expiresIn-ის შემოკლება, ხოლო JWT_SECRET-ის შეცვლა გადაუდებელი მუხრუჭია, რომელიც ყველას ერთბაშად აუქმებს იმ ფასად, რომ ყველა საბოლოო მომხმარებელი გამოდის სისტემიდან. Strapi-ის პროდაქშენის სახელმძღვანელოში ჩამოთვლილია დანარჩენი საიდუმლოები და ის, თუ რა ტყდება თითოეულის შეცვლისას.

API ტოკენები: შეზღუდული, ვადიანი, თითო მომხმარებელზე ერთი#

API ტოკენი პროგრამისთვის სწორი ავტორიზაციის მონაცემია. Settings, Global settings, API Tokens-ში აირჩიე Create new API Token. უნდა შეავსო ოთხი რამ.

• სახელი და აღწერა: გამოიყენე მომხმარებელი სისტემის სახელი, მაგალითად marketing-site-build. როცა ტოკენი გაჟონავს, სახელით გაიგებ, რომელი სისტემა უნდა გაასწორო.
• Token duration: 7 days, 30 days, 90 days ან Unlimited. აირჩიე ყველაზე მოკლე ვადა, რომლის განახლებასაც მზად ხარ. Unlimited შეგნებული არჩევანი უნდა იყოს და არა დიალოგის სწრაფად დახურვის საშუალება.
• Token type: Read-only, Full access ან Custom.

სამი ტიპი ზიანის მასშტაბით ძალიან განსხვავდება:

Full access-ს მოერიდე. ტოკენი, რომელსაც ყველა ჩანაწერზე delete-ის გაკეთება შეუძლია, აწყობის სკრიპტში, რომელიც, თანაც, CI სერვერზე სრულდება და სხვებისთვის წაკითხვადია, ძალიან ძვირი დასაკარგია. Read-only ჩაწერისგან დაცულია, მაგრამ მაინც ფარავს კონტენტის ყველა ტიპს, იმათაც, რომლებიც მომხმარებელს არ სჭირდება. Custom საშუალებას გაძლევს, მონიშნო ზუსტად find და findOne იმ ორ ტიპზე, რომელსაც ფრონტენდი აჩვენებს, და არაფერი მეტი, და სწორედ ეს უნდა იყოს შენი საწყისი წერტილი.

შენახვისას ტოკენის მნიშვნელობა ნაჩვენები იქნება. Strapi ინახავს ტოკენის ჰეშს, რომელიც API_TOKEN_SALT მარილითაა მიღებული, ამიტომ ტიპურ კონფიგურაციაში მნიშვნელობის კოპირება მხოლოდ ამ მომენტში შეგიძლია. უფრო ახალ 5.x რელიზებს შეუძლიათ ტოკენის ხელახლა ჩვენება, თუ დაყენებულია დაშიფვრის გასაღები (ENCRYPTION_KEY, რომელსაც config/admin.js დაგენერირებულ პროექტში secrets.encryptionKey-ად კითხულობს); თუ ის შენს .env-ში გაქვს, ისევე უცვლელად შეინახე, როგორც დანარჩენი საიდუმლოები. ყოველ შემთხვევაში, მნიშვნელობა პირდაპირ იმ სისტემის საიდუმლოების საცავში ჩადე, რომელიც მას გამოიყენებს.

გამოიყენე ის როგორც bearer ტოკენი:

$ curl -i https://cms.example.com/api/articles \    -H "Authorization: Bearer $STRAPI_TOKEN"

შეამოწმე საზღვარიც, არა მარტო წარმატება. Custom ტოკენით, რომელსაც მხოლოდ articles-ზე აქვს find:

$ curl -i https://cms.example.com/api/pages -H "Authorization: Bearer $STRAPI_TOKEN"$ curl -i -X DELETE https://cms.example.com/api/articles/abc123 \    -H "Authorization: Bearer $STRAPI_TOKEN"

ორივემ უნდა გიპასუხოს 403. არასწორი ან ვადაგასული ტოკენი იძლევა 401 Unauthorized-ს; ვალიდური ტოკენი, რომელსაც ეს მოქმედება არ შეუძლია, იძლევა 403-ს. ამ ორის გარჩევა ბევრ გამართვის დროს გიზოგავს: 401 იმაზეა, ვინ ხარ, 403 კი იმაზე, რა გაქვს უფლება.

რამდენიმე ჩვევა ტოკენებს მართვადს ხდის:

1. ერთი ტოკენი თითო მომხმარებელზე. თუ სატესტო და ძირითადი საიტი ერთ ტოკენს იზიარებს, ერთს ვერ გააუქმებ მეორის გაფუჭების გარეშე.
2. ტოკენს ბრაუზერში ნურასოდეს გაგზავნი. ყველაფერი, რაც კლიენტის ბანდლშია, საჯაროა. ტოკენი NEXT_PUBLIC_-ში ან მსგავს ცვლადში Public უფლებაა დამატებითი ნაბიჯებით. თუ ბრაუზერს მონაცემები სჭირდება, გახადე ისინი საჯარო Public როლით (მხოლოდ წაკითხვა, რამდენიმე ტიპი) და ტოკენი სერვერული კოდისთვის შეინახე.
3. ეჭვის შემთხვევაში ხელახლა დააგენერირე. ტოკენის რედაქტირების გვერდზე არის Regenerate ღილაკი, რომელიც ახალ მნიშვნელობას გასცემს და ძველს აუქმებს. უფლებები რჩება.
4. განაახლე კალენდრით. 90-დღიანი ტოკენების შემთხვევაში კალენდარში ჩანაწერი ვადის გასვლამდე ორი კვირით გაჭედვაზე იაფია.
5. ტოკენები ჰოსტის გარემოში შეინახე და არა რეპოზიტორიაში. რატომ, ამას განმარტავს ტექსტი გარემოს ცვლადები და საიდუმლოები.

API ტოკენები მხოლოდ content API-ზე მოქმედებს. ისინი ადმინ პანელში ვერ შევლენ და ვერ შეცვლიან კონტენტის ტიპებს, როლებს ან პარამეტრებს.

Transfer ტოკენები სულ სხვაა

იმავე Global settings-ში Transfer Tokens-საც იპოვი. ისინი ანიჭებენ უფლებას strapi transfer-ზე, Strapi-ის ორ ეგზემპლარს შორის მონაცემების პირდაპირ კოპირებაზე, და Push ან Pull მიმართულებით გაიცემა. მათი მარილია TRANSFER_TOKEN_SALT. Pull მიმართულების transfer ტოკენს შეუძლია შენი მთელი კონტენტისა და მედიის წაკითხვა. შექმენი ის მხოლოდ იმ მომენტისთვის, როცა გჭირდება, მიეცი უმოკლესი ვადა და შემდეგ წაშალე.

ადმინ მომხმარებლები და ადმინ როლები#

ადმინ მომხმარებლები ადამიანები არიან, რომლებიც /admin-ზე შედიან. Settings, Administration Panel, Roles-ში ახალ ინსტალაციაზე სამი როლია:

პირველი ადამიანი, რომელიც ახალ ინსტალაციაზე /admin-ს გახსნის, Super Admin-ს ქმნის. გააკეთე ეს თვითონ, დაუყოვნებლივ, სანამ სერვერზე საჯარო დომენს მიუთითებ. ამის შემდეგ წესი ასეთია: Super Admin თითქმის არავინ უნდა იყოს. ეს ერთადერთი როლია, რომელსაც შეუძლია API ტოკენების შექმნა, Public როლის შეცვლა, პლაგინების დაყენება და სხვა ადმინების მოწვევა, და მისი შეცვლა ან შეზღუდვა შეუძლებელია.

ადამიანები მოიწვიე Settings, Administration Panel, Users-ში, ღილაკით Invite new user. თუ სერვერზე საფოსტო პროვაიდერია, ისინი ბმულს მიიღებენ. თუ არა, Strapi გაჩვენებს რეგისტრაციის ბმულს, რომელიც უნდა დააკოპირო და ხელით გაგზავნო; ის გამოყენების შემდეგ ძალას კარგავს და საჯარო არხში ნუ ჩასვამ. ახალი ადმინი ამ ბმულზე თვითონ ირჩევს პაროლს.

ჩაშენებულ როლებს სიზუსტე აკლია. გაამრავლე Editor ან Author და ასლი შეცვალე. ყოველი როლი არის კონტენტის ტიპებისა და მოქმედებების ბადე (Create, Read, Update, Delete, Publish), პლუს ველები ყოველი ტიპის შიგნით, პლუს Plugins და Settings განყოფილებები. პრაქტიკულს ამას ორი შესაძლებლობა ხდის:

• ველების დონის უფლებები. კონტენტის ტიპში გახსენი ველები და მოხსენი ის ველები, რომლებიც როლმა არ უნდა ნახოს ან შეცვალოს. კარგი მაგალითია ფასის ველი, რომელსაც მხოლოდ მენეჯერები ცვლიან.
• პირობები. უფლება შეიძლება შეიზღუდოს პირობით, მაგალითად „Is creator“, ასე რომ Author-ს შეუძლია საკუთარი შექმნილი ჩანაწერების შეცვლა და სხვის ჩანაწერებს ვერ შეეხება. პირობის გარეშე უფლება ყოველ ჩანაწერზე მოქმედებს.

Settings-ის უფლებებს ცალკე ყურადღება სჭირდება. როლს შეიძლება მიეცეს API ტოკენების წაკითხვის ან შექმნის, ან როლების წაკითხვის უფლება, სხვა რამეზე შეხების უფლების გარეშე. ეს უფლებები მხოლოდ მათ მიეცი, ვინც საიტს მართავს.

რა გააკეთო ყოველ ინსტალაციაზე:

1. შექმენი საკუთარი სახელობითი Super Admin და მეორე, საგანგებო შემთხვევისთვის შენახული, ერთი საერთო შესვლის ნაცვლად.
2. გამოიყენე ყოველი ადამიანის ნამდვილი ელფოსტა. საერთო admin@ ყუთი მოქმედებების კვალს უსარგებლოს ხდის, ხოლო პაროლის ყოველ აღდგენას მოლაპარაკებად აქცევს.
3. როცა ვინმე მიდის, გააუქმე მისი ანგარიში (Users სიაში აქტიურობის გადამრთველია) და ნუ დაელოდები ვადის გასვლას.
4. გამოიყენე გრძელი უნიკალური პაროლები პაროლების მენეჯერიდან. Strapi-ის community გამოცემას ადმინ პანელისთვის ჩაშენებული ორფაქტორიანი შესვლა არ აქვს; ერთიანი შესვლა (SSO) ფასიანი გამოცემების ნაწილია. თუ ეს შენთვის მნიშვნელოვანია, შეამოწმე Strapi-ის დოკუმენტაცია შენი ვერსიისთვის.

თუ საკუთარ თავს გამოკეტავ, ბაზაში ჩარევა საჭირო არ არის. პროექტის დირექტორიიდან CLI-ს შეუძლია ახალი Super Admin-ის შექმნა ან პაროლის გადატვირთვა:

$ npm run strapi admin:create-user -- --firstname=Ada --lastname=Admin \    --email=ada@example.com --password='a-long-unique-password'$ npm run strapi admin:reset-user-password -- --email=ada@example.com --password='another-one'

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

უფლებები კოდიდან და არა დაწკაპუნებით#

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

შაბლონი, რომელსაც Strapi-ის დემო პროექტები იყენებს, არის bootstrap ფუნქცია src/index.js-ში, რომელიც როლს პოულობს და საჭირო უფლების ჩანაწერებს ქმნის. მოქმედებები ასე იწოდება: api::<singular>.<singular>.<action>:

module.exports = {  register() {},  async bootstrap({ strapi }) {    const publicRole = await strapi.db      .query('plugin::users-permissions.role')      .findOne({ where: { type: 'public' } });    const actions = ['api::article.article.find', 'api::article.article.findOne'];    for (const action of actions) {      const existing = await strapi.db        .query('plugin::users-permissions.permission')        .findOne({ where: { action, role: publicRole.id } });      if (!existing) {        await strapi.db          .query('plugin::users-permissions.permission')          .create({ data: { action, role: publicRole.id } });      }    }  },};

ეს კოდი უფლებებს მხოლოდ ამატებს და ვერასოდეს აშორებს იმას, რაც ვინმემ ხელით მონიშნა, ამიტომ ის ქვედა ზღვარია და არა ბოქლომი. ამის მიუხედავად, ახალი გარემო საჯარო გვერდებს ხელით გადაყოლის გარეშე მოემსახურება, ხოლო საჯაროს სია ვერსიების კონტროლშია, სადაც მიმომხილველი ნახავს. article შეცვალე შენი კონტენტის ტიპის სახელით მხოლობით რიცხვში.

პერიმეტრის გამაგრება: პროქსი, CORS და სიხშირის შეზღუდვა#

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

CORS იწერება strapi::cors middleware-ით config/middlewares.js-ში. ნაგულისხმევად ნებისმიერ origin-ს უშვებს. CORS ბრაუზერის წესია და curl-ს ვერ აჩერებს, მაგრამ მკაცრი სია უცხო საიტებს უშლის ხელს, შენს API-ს თავიანთი სტუმრების ბრაუზერებიდან მიმართონ:

module.exports = [  'strapi::logger',  'strapi::errors',  'strapi::security',  {    name: 'strapi::cors',    config: {      origin: ['https://www.example.com'],      methods: ['GET', 'HEAD', 'OPTIONS'],      headers: ['Content-Type', 'Authorization'],      keepHeaderOnError: true,    },  },  'strapi::poweredBy',  'strapi::query',  'strapi::body',  'strapi::session',  'strapi::favicon',  'strapi::public',];

middleware-ების რიგი ისე დატოვე, როგორც დაგენერირებულ ფაილშია, და შეცვალე მხოლოდ strapi::cors ჩანაწერი. ადმინ პანელი იმავე origin-იდან გაიცემა, საიდანაც API, ამიტომ ფრონტენდის origin-ების სია მას არ ეხება.

სიხშირის შეზღუდვა რევერს პროქსიზე უნდა იყოს იმ მარშრუტებისთვის, სადაც გამოცნობა ხდება: ადმინ პანელში შესვლა /admin/login და საბოლოო მომხმარებლების შესვლა და რეგისტრაცია /api/auth/local-ის ქვეშ. თვით Strapi-ს ადმინის შესვლისთვის საკუთარი შეზღუდვის პარამეტრები აქვს (admin.rateLimit ბლოკი config/admin.js-ში) და ღირს მათი ჩართვა, მაგრამ პროქსიზე ლიმიტი Strapi-ის ნებისმიერ ვერსიაზე ერთნაირად მუშაობს და პროცესსაც ტვირთისგან იცავს. nginx-ში:

limit_req_zone $binary_remote_addr zone=strapi_auth:10m rate=10r/m;server {    # ... TLS and the usual proxy_pass block ...    location = /admin/login {        limit_req zone=strapi_auth burst=5 nodelay;        proxy_pass http://127.0.0.1:1337;    }    location /api/auth/ {        limit_req zone=strapi_auth burst=5 nodelay;        proxy_pass http://127.0.0.1:1337;    }}

ზედმეტი მოთხოვნები ნაგულისხმევად 503-ს იღებს; დაამატე limit_req_status 429;, თუ უფრო ზუსტი კოდი გირჩევნია. პროქსის დანარჩენი მოწყობა აღწერილია nginx-ის რევერს პროქსის სახელმძღვანელოში, ხოლო ტექსტი ფაირვოლის წესები, რომლებსაც მნიშვნელობა აქვს გიჩვენებს, როგორ დაიტოვო Node-ის პორტი საჯარო ინტერნეტის მიღმა, თუ პროქსი იმავე მანქანაზე მუშაობს.

კიდევ ერთი სტრუქტურული ვარიანტი ღირს, იცოდე: ადმინ პანელი და API ერთად საჯარო არ უნდა იყოს. თუ რედაქტორები ცნობილი ქსელებიდან მუშაობენ, პროქსიზე /admin მისამართით შეგიძლია შეზღუდო და /api ფრონტენდისთვის ღია დატოვო. ეს დამატებითი ფენაა და არა როლების შემცვლელი.

Strapi RE:NODE-ზე#

RE:NODE-ზე Strapi ერთი დაწკაპუნებით დასაყენებელი აპლიკაციაა აპლიკაციების ჰოსტინგის გვერდზე. ის სერვერის პირველ გაშვებაზე დგება და ტარდება, მონაცემები SQLite-შია სერვერზე, ამიტომ დაცვა პირველი გაშვების დასრულებისთანავე იწყება: გახსენი /admin, შექმენი Super Admin და ამ სახელმძღვანელოს ნაბიჯები გაიარე, სანამ მისამართს ვინმეს გაუზიარებ. პროქსის სლოტი სერთიფიკატს გასცემს, როგორც კი A ჩანაწერი ნაჩვენებ მისამართზე მიუთითებს, ხოლო კლიენტის ნამდვილი IP მოდის X-Forwarded-For-ში, რაც ზემოთ აღწერილი სიხშირის შეზღუდვებისთვის მნიშვნელოვანია.

არსებობს უფლებათა მეორე ნაკრებიც, რომლის გამოყენებაც ღირს, და ეს თვით პანელის უფლებებია. სერვერის ქვემომხმარებლებს შეიძლება მიეცეთ დეტალური უფლებები, მაგალითად მხოლოდ კონსოლი ან მხოლოდ ფაილები, ხოლო ყოველ სერვერს აქტივობის ჟურნალი აქვს, ამიტომ ვისაც მხოლოდ ლოგების წაკითხვა სჭირდება, არ უნდა შეეძლოს .env ფაილის რედაქტირება, სადაც შენი Strapi-ის საიდუმლოებია. ადამიანებისა და როლების შესახებ პანელში წაიკითხე გიდებში. ჩართე TOTP ორფაქტორიანი შესვლა შენი საკუთარი პანელის ანგარიშისთვისაც: ვინც შენს პანელის ანგარიშს აკონტროლებს, ფაილების მენეჯერსაც აკონტროლებს და მასთან ერთად პროექტის ყველა საიდუმლოს.

Strapi-ის .env პროექტის საქაღალდეშია და მისი რედაქტირება ფაილების მენეჯერში ან SFTP-ით შეიძლება. რადგან როლები, უფლებები და API ტოკენები ბაზაში ინახება, მათ იცავს ხელით ან Schedules ჩანართზე შექმნილი backup-ის სლოტი; დროდადრო აღადგინე ერთ-ერთი, რომ დარწმუნდე, მუშაობს: ტოკენები დაბრუნდება მხოლოდ იმ შემთხვევაში, თუ .env-ში მარილი იგივეა, რაც იყო.

შედეგის შემოწმება#

ეს მოკლე სია გაიარე როლების ყოველი ცვლილების შემდეგ და ყოველ ახალ გარემოში. ხუთ წუთს მოითხოვს და გავრცელებულ შეცდომებს იჭერს.

1. ანონიმური, დახურული ტიპი. გააკეთე curl -i კონტენტის ტიპზე, რომელიც არ გაგიხსნია. მოელოდე 403-ს.
2. ანონიმური, ღია ტიპი. გააკეთე curl -i გახსნილზე. მოელოდე 200-ს და მხოლოდ იმ ველებს, რომელთა გამოქვეყნებაც გინდოდა.
3. ანონიმური, ჩაწერა. გააკეთე curl -i -X POST ღია კოლექციაზე პატარა JSON სხეულით, როგორიცაა {"data":{}}. მოელოდე 403-ს.
4. ანონიმური, მომხმარებლები. curl -i https://cms.example.com/api/users. მოელოდე 403-ს.
5. რეგისტრაცია. curl -i -X POST https://cms.example.com/api/auth/local/register JSON სხეულით. თუ რეგისტრაცია გამორთულია, მოელოდე შეცდომას და არა ახალ ანგარიშსა და JWT-ს.
6. ტოკენი, ფარგლებში. მოითხოვე ის, რისთვისაც ტოკენია განკუთვნილი. მოელოდე 200-ს.
7. ტოკენი, ფარგლებს გარეთ. მოითხოვე ის, რასაც ვერ უნდა წვდებოდეს. მოელოდე 403-ს.
8. არასწორი ტოკენი. შეცვალე ერთი სიმბოლო. მოელოდე 401-ს.
9. ადმინ ანგარიშები. გადახედე Settings, Administration Panel, Users-ს და წაშალე ან გააუქმე ყველა, ვისაც არ იცნობ. დათვალე Super Admin-ები.
10. API Tokens სია. წაშალე ყოველი ტოკენი, რომლის სახელსაც ვერავინ ხსნის, და ყოველი Full access ტოკენი, რომლის Custom-ით ჩანაცვლებაც შეიძლება.

თუ შემოწმება ჩავარდა, ნუ დაჯერდები მხოლოდ ინტერფეისში გასწორებას. ჩაიწერე, როგორი უნდა იყოს სწორი მდგომარეობა, დააყენე ის და შემოწმება თავიდან გაუშვი. უფლებების გვერდის არასწორად წაკითხვა ადვილია, სტატუსის კოდისა კი არა.

პრობლემების აღმოფხვრა#

`403 Forbidden` ტიპზე, რომელიც გახსენი. როლი შეინახა, მაგრამ მოთხოვნა სხვა როლს მიაკუთვნეს. შეამოწმე, ხომ არ გაგიგზავნია Authorization ჰედერი: საბოლოო მომხმარებლის ვალიდური JWT Authenticated როლს იყენებს, რომელსაც საკუთარი უფლებების ბადე აქვს და შეიძლება არ ჰქონდეს ის, რაც Public-ს აქვს. დარწმუნდი ისიც, რომ სწორი მოქმედებაა მონიშნული, find ან findOne; ID-ით მოთხოვნილ ჩანაწერს findOne სჭირდება.

`401 Unauthorized` ტოკენით, რომელიც სწორი ჩანდა. ჰარი ან ახალი ხაზი მნიშვნელობის დასაწყისში ან ბოლოში, Bearer პრეფიქსის არარსებობა, ვადაგასული ტოკენი ან შეცვლილი API_TOKEN_SALT. შექმენი ახალი ტოკენი, რომ მარილი გამოირიცხო.

`403` ტოკენისთვის რედაქტირების შემდეგ. ტიპი Custom-ზე გადართე და შეინახე არაფრის მონიშვნის გარეშე. Custom ტოკენი მოქმედებების გარეშე არაფერს უშვებს.

ყველა ტოკენმა შეწყვიტა მუშაობა მიგრაციის შემდეგ. მარილი განსხვავდება იმისგან, რომლითაც ტოკენები დაიჰეშა. აღადგინე API_TOKEN_SALT ძველი გარემოს .env-იდან, ან გამოუშვი ახალი ტოკენები და თითოეული მომხმარებელი განაახლე.

უფლებები გაქრა თავიდან შექმნილ სერვერზე. ისინი ბაზაში იყო, ბაზა კი ახალია. აღადგინე backup, რომელიც მას შეიცავს, ან გამოიყენე bootstrap ფუნქცია, როგორც ზემოთ.

კონტენტის ახალი ტიპი ფრონტენდს არ ჩანს. ის დახურული იწყებს. გახსენი find და findOne სწორ როლზე ან ტოკენზე და ხელახლა შეამოწმე.

Settings-ში Roles გვერდი არ არის. შენს ადმინ როლს როლების წაკითხვის უფლება არ აქვს. სთხოვე Super Admin-ს.

FAQ#

რით განსხვავდება Public როლი API ტოკენისგან?

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

უსაფრთხოა თუ არა Read-only API ტოკენის ფრონტენდში ჩასმა?

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

შეიძლება თუ არა ისეთი API ტოკენის შექმნა, რომელიც მხოლოდ ერთ ტიპს კითხულობს?

დიახ. შექმენი Custom ტიპის ტოკენი და მონიშნე find და findOne მხოლოდ ამ ტიპისთვის. სხვა ტიპზე შეამოწმე, რომ 403 დაბრუნდება.

როგორ შევუშალო ხელი უცხოებს ანგარიშების რეგისტრაციაში?

Settings-ში, Users and Permissions plugin, Advanced settings, გამორთე Enable sign-ups. შემდეგ გააგზავნე POST მისამართზე /api/auth/local/register და დარწმუნდი, რომ ანგარიში არ შეიქმნა. თუ რეგისტრაცია გჭირდება, ელფოსტის დადასტურება ჩართული დატოვე და ამ მარშრუტზე მოთხოვნათა სიხშირე შეზღუდე.

რატომ წყვეტს Strapi-ის API ტოკენი მუშაობას ხელახალი დეპლოის შემდეგ?

თითქმის ყოველთვის იმიტომ, რომ API_TOKEN_SALT შეიცვალა. ტოკენები ამ მარილით იჰეშება, ამიტომ განსხვავებული მნიშვნელობა ყველა შენახულ ტოკენს ამოუცნობს ხდის. პროდაქშენის .env აწყობებს შორის უცვლელად შეინახე.

გადადის თუ არა როლები და უფლებები კოდთან ერთად?

არა. ისინი ბაზაში ინახება. დეპლოი ან strapi export არქივი მათ სხვა გარემოში საიმედოდ არ გადააქვს, ამიტომ შეამოწმე ისინი ყოველ გარემოში, ან Public-ის უფლებები bootstrap ფუნქციაში ჩაწერე, რომ ახალი გარემო სწორი სიით დაიწყოს.