Ադմին վահանակներ և CMS

01Ինչ է պետք յուրաքանչյուր ադմինի

Սկսեք ադմինի օգտատերերից, ոչ թե տվյալների բազայի աղյուսակներից։ Պատվերներով զբաղվող օպերատորին պետք է պատվերների արագ ցուցակ՝ կարգավիճակի ֆիլտրերով և իրական ժամանակի թարմացումներով։ Կոնտենտ մենեջերին պետք են էջեր, բլոգ, մեդիա և SEO։ Մարքեթոլոգին պետք են ակցիաներ, սեգմենտներ և արշավներ։ Մենեջերին պետք են հաշվետվություններ։ Նրանց բոլորի հետևում նույն շինանյութն է՝ նույնականացում (իդեալում՝ երկրորդ գործոնով կամ մեկանգամյա կոդերով ադմինների համար), դերեր և թույլտվություններ, CRUD էկրաններ (create, read, update, delete)՝ որոնմամբ, ֆիլտրերով, դասավորմամբ և pagination-ով, զանգվածային գործողություններ, մեդիա գրադարան, կարգավորումներ, հաշվետվություններ export-ներով և audit log։ Ծանուցումները՝ web push կամ in-app, աշխատակիցներին տեղեկացնում են նոր պատվերների կամ ձախողված sync-երի մասին։

• Ցուցակներ՝ server-side pagination, ֆիլտրերը URL-ում, որպեսզի դիտումները կարելի լինի կիսել։
• Ձևեր՝ վալիդացիա սերվերում, հստակ սխալներ, նախազգուշացում չպահպանված փոփոխությունների մասին։
• Զանգվածային գործողություններ՝ հաստատմամբ և փոփոխվածի ամփոփումով։

02Դերեր, թույլտվություններ և audit log-եր

Դերը թույլտվությունների անվանված փաթեթ է («պատվերների օպերատոր», «կոնտենտի խմբագիր»), իսկ թույլտվությունը մեկ գործողություն է ռեսուրսի վրա, օրինակ՝ orders.view կամ products.update։ Թույլտվությունները ստուգեք սերվերում յուրաքանչյուր հարցման համար․ UI-ում կոճակը թաքցնելը հարմարություն է, ոչ թե անվտանգություն։ Թույլտվությունների անունները պահեք հետևողական, որպեսզի ադմինի մենյուն, route-երը և կոճակները կարողանան կարդալ նույն ցուցակը։ Զգայուն գործողությունների համար, օրինակ՝ վերադարձներ, մնացորդի ձեռքով փոփոխություններ կամ դերերի փոփոխություններ, ավելացրեք լրացուցիչ դիմադրություն՝ պատճառի դաշտ, հաստատում, գուցե երկրորդ հաստատող։ Audit log-ը գրանցում է, թե ով ինչ արեց, երբ, որ գրառման հետ, և արժեքները՝ առաջ և հետո։ Երբ production-ում ինչ-որ բան սխալ է գնում, audit log-ը գուշակությունը վերածում է երկու րոպեանոց որոնման։

1// Laravel: one permission check per action, enforced on the server
2Route::middleware(['auth:admin', 'can:orders.refund'])
3    ->post('/admin/orders/{order}/refund', RefundOrderController::class);
4 
5// Audit every sensitive change with before/after values
6AuditLog::create([
7    'admin_id'   => $request->user()->id,
8    'action'     => 'order.refunded',
9    'subject'    => $order->getMorphClass().':'.$order->id,
10    'before'     => ['status' => $before],
11    'after'      => ['status' => $order->status, 'amount' => $amount],
12    'reason'     => $request->string('reason'),
13    'ip'         => $request->ip(),
14]);

03Config-driven CRUD

Ադմինի էկրանների մեծ մասը տարբերվում է միայն դաշտերով և սյունակներով։ Յուրաքանչյուր ցուցակ և ձև ձեռքով գրելու փոխարեն ռեսուրսը նկարագրեք կոնֆիգուրացիայում՝ API endpoint-ը, ցուցակի սյունակները, ֆիլտրերը, ձևի դաշտերը տիպերով (text, number, select, rich text, image, slug, կատեգորիաների ծառ) և թույլտվությունները։ Ընդհանուր շարժիչը այդ նկարագրությունից ցուցադրում է ցուցակն ու ձևը, այնպես որ նոր ռեսուրսը րոպեներ է պահանջում, և յուրաքանչյուր էկրան ստանում է նույն pagination-ը, վալիդացիայի ցուցադրումը և զանգվածային գործողությունները։ Backend-ում ընդհանուր resource controller-ը կարող է սպասարկել ստանդարտ CRUD-ը, իսկ custom endpoint-ները՝ հատուկ տրամաբանությունը։ Պահեք «escape hatch»․ որոշ էկրաններ՝ պատվերի մանրամասների էջ, ակցիաների կառուցիչ, dashboard, արժանի են custom կոմպոնենտների, և config համակարգը պետք է թույլ տա դրանք միացնել։

1export const brandsResource = {
2  name: "brands",
3  endpoint: "/admin/brands",
4  permission: "brands",
5  list: {
6    columns: ["logo", "name", "productsCount", "isActive"],
7    filters: [{ field: "isActive", type: "boolean" }],
8    search: ["name"],
9  },
10  form: [
11    { name: "name", type: "text", required: true, translatable: true },
12    { name: "slug", type: "slug", from: "name" },
13    { name: "logo", type: "media", accept: "image/*" },
14    { name: "description", type: "richText", translatable: true },
15    { name: "seo", type: "seo" },
16  ],
17} as const;

04Մեդիա գրադարան և SEO դաշտեր

Մեդիա գրադարանը վերբեռնումները պահում է մեկ անգամ և թույլ է տալիս խմբագիրներին կրկին օգտագործել դրանք՝ թղթապանակներ, որոնում, crop, փոխարինում (հղումները պահպանելով), alt տեքստ և օգտագործման հետևում։ Վալիդացրեք վերբեռնումները ըստ բովանդակության, ոչ միայն ֆայլի ընդլայնման, սահմանափակեք չափն ու չափսերը, հեռացրեք metadata-ն և գեներացրեք փոքրացված տարբերակներ, օրինակ՝ WebP thumbnail-ներ, background job-ում։ Երբ կայքն աճում է, ֆայլերը պահեք object storage-ում (S3-համատեղելի) CDN-ի հետևում, ոչ թե հավելվածի սերվերի դիսկում։ SEO դաշտերը պետք է լինեն յուրաքանչյուր հանրային մոդելի վրա՝ slug, meta title, meta description, social image, canonical URL և noindex անջատիչ, կոնտենտից գեներացված խելամիտ default-ներով։ Ադմինը պետք է նաև կառավարի redirect-ները, որովհետև վերանվանված slug-երը այլապես կոտրված հղումներ են ստեղծում, իսկ կայքը պետք է իր sitemap-ը գեներացնի նույն տվյալներից։

05Հաշվետվություններ և export-ներ

Հաշվետվությունները պատասխանում են բիզնես հարցերի՝ վաճառքներն ըստ օրերի և ալիքների, լավագույն ապրանքներ, նոր և վերադարձող հաճախորդներ, ակցիաների արժեք, առաքման միջին ժամանակ։ Կառուցեք դրանք հաշվետվությունների համար նախատեսված query-ների վրա՝ ագրեգացված աղյուսակներ, read replica-ներ կամ գիշերային ամփոփումներ, որպեսզի ծանր հաշվետվությունը երբեք չդանդաղեցնի checkout-ը։ Միշտ ցույց տվեք ամսաթվերի միջակայքը և ժամային գոտին, և համոզվեք, որ թվերը համընկնում են պատվերների ցուցակի հետ («վճարվածի» նույն սահմանումն ամենուր)։ Excel կամ CSV export-ները էական են, քանի որ ֆինանսներն ու մարքեթինգն ապրում են աղյուսակներում։ Մեծ export-ները գեներացրեք queue-ի job-ում, տողերը stream արեք՝ ամեն ինչ հիշողության մեջ բեռնելու փոխարեն, և պատրաստ լինելուն պես ուղարկեք ներբեռնման հղում։ Export-ները պարունակում են անձնական տվյալներ, ուստի պաշտպանեք դրանք թույլտվություններով, կարճաժամկետ հղումներով և audit գրառումով։

06Ներկառուցված CMS, թե՞ headless CMS

CMS-ը (content management system) թույլ է տալիս ոչ ծրագրավորողներին խմբագրել էջեր և կոնտենտ։ Ներկառուցված CMS-ն ապրում է ձեր սեփական ադմինի և տվյալների բազայի ներսում՝ էջեր, բլոգ, FAQ, բաններներ և բլոկներ՝ ապրանքների և պատվերների կողքին։ Այն իդեալական է, երբ կոնտենտը սերտորեն կապված է commerce տվյալների հետ, և ոչ մի լրացուցիչ արժեք չունի։ Headless CMS-ը (Contentful, Sanity, Strapi, Payload) առանձին ծառայություն է, որը պահում է կոնտենտը և մատուցում այն API-ով․ այն փայլում է խմբագրական թիմերի, հարուստ բլոկային layout-ների, preview-ների և workflow-ների համար։ Հիբրիդը տարածված է՝ կառուցվածքային բիզնես տվյալները ձեր սեփական backend-ում, խմբագրական կոնտենտը՝ headless CMS-ում։ Ինչ էլ ընտրեք, կոնտենտը մոդելավորեք որպես տիպավորված բլոկներ, ոչ թե մեկ հսկա HTML դաշտ, որպեսզի frontend-ը վերահսկի դիզայնը, իսկ կոնտենտը մնա շարժական։

07Authorisation դերերից այն կողմ. scope-եր և policy-ներ

Role-based access control-ը (RBAC) պատասխանում է «կարո՞ղ է այս մարդը refund անել պատվերները» հարցին, բայց ոչ «կարո՞ղ է նա refund անել այս մասնաճյուղի պատվերները» հարցին։ Իրական back office-ներին պետք են երկուսն էլ։ Permission-ները համատեղեք scope-երի հետ. մասնաճյուղի մենեջերն ունի orders.refund՝ սահմանափակված իր մասնաճյուղերով, մատակարարի օգտատերը տեսնում է միայն իր ապրանքները։ Ստուգումն իրականացրեք յուրաքանչյուր resource-ի համար մեկ տեղում՝ policy class-ում, որն ընդունում է օգտատիրոջը, գործողությունը և գրառումը, և նույն scope-ը կիրառեք ցուցակների query-ների վրա, որպեսզի մարդիկ նույնիսկ չտեսնեն այն տողերը, որոնց չեն կարող դիպչել։ Սա քայլ է դեպի attribute-based access control (ABAC), որտեղ կանոններն օգտագործում են օգտատիրոջ և գրառման ատրիբուտները։ Յուրաքանչյուր օգտատիրոջ permission-ները cache արեք յուրաքանչյուր request-ի համար, invalidate արեք cache-ը, երբ դերերը փոխվում են, և թեստեր գրեք յուրաքանչյուր զգայուն policy-ի համար, որովհետև authorisation-ի bug-երը լուռ են, մինչև տվյալներ չարտահոսեն։

1// Laravel policy: permission plus scope in one place
2class OrderPolicy
3{
4    public function refund(Admin $admin, Order $order): bool
5    {
6        return $admin->can('orders.refund')
7            && $admin->branches()->whereKey($order->branch_id)->exists();
8    }
9}
10 
11// The same scope applied to list queries
12Order::query()
13    ->whereIn('branch_id', $admin->branches()->pluck('branches.id'))
14    ->latest()
15    ->paginate(50);

08Audit log-եր, որոնք դիմանում են միջադեպին

Audit log-ը օգտակար է միայն այն դեպքում, եթե մարդիկ վստահում են դրան։ Գրառումները գրեք service layer-ում, որպեսզի էկրաններից, API կանչերից, import-ներից և console հրամաններից եկող փոփոխությունները բոլորը գրանցվեն։ Ամբողջ տողերի փոխարեն գրանցեք փոխված դաշտերի diff-ը և դիմակավորեք գաղտնիքներն ու զգայուն անձնական տվյալները։ Աղյուսակը դարձրեք append-only. application-ի database օգտատերը կարող է insert անել, բայց ոչ update կամ delete, իսկ retention-ի մաքրումը կատարվում է առանձին արտոնյալ job-ով։ Յուրաքանչյուր գրառման ավելացրեք request ID, որպեսզի admin-ի մեկ գործողությունը, որը դիպչում է տասը գրառման, հետևվի որպես մեկ event։ Բարձր արժեք ունեցող գործողությունների համար log արեք նաև ընթերցումները. ով է export արել հաճախորդների ցուցակը, ով է դիտել քարտապանի ամբողջական հասցեն։ Audit տվյալները պահեք բավականաչափ երկար dispute-ների և կարգավորումների համար և դրանք դարձրեք որոնելի՝ ըստ գրառման, մարդու և ժամանակահատվածի։

1-- Append-only for the application user
2REVOKE UPDATE, DELETE ON audit_logs FROM app_user;
3GRANT INSERT, SELECT ON audit_logs TO app_user;
4 
5CREATE INDEX audit_logs_subject_idx ON audit_logs (subject_type, subject_id, created_at DESC);
6CREATE INDEX audit_logs_actor_idx   ON audit_logs (admin_id, created_at DESC);

09Admin-ի արտադրողականություն մեծ աղյուսակների դեպքում

Admin-ի ցուցակները հաճախ դառնում են համակարգի ամենադանդաղ մասը. միլիոնավոր տողերով պատվերների աղյուսակ, տասնյակ ֆիլտրեր և ընդհանուր count յուրաքանչյուր էջում։ Index-եր ստեղծեք այն ֆիլտրերի համար, որոնք մարդիկ իրականում օգտագործում են, սովորաբար composite index-եր, որոնք սկսվում են status-ով կամ մասնաճյուղով և ավարտվում ստեղծման ամսաթվով։ Հսկայական ֆիլտրված աղյուսակների ճշգրիտ ընդհանուր count-երը թանկ են. որոշակի շեմից հետո ցույց տվեք «շատ արդյունքներ» կամ մոտավոր թիվ, կամ հաշվեք ասինխրոն։ Offset pagination-ը խորը էջերում վատանում է, որովհետև database-ը միևնույն է անցնում է բաց թողնված տողերով, իսկ keyset (cursor) pagination-ը մնում է արագ։ Խուսափեք N+1 query-ներից՝ eager-load անելով սյունակներում ցուցադրվող relation-ները։ Բազմաթիվ տեքստային սյունակներով որոնումը պետք է լինի search engine-ում կամ full-text index-ում, ոչ թե LIKE-երի շղթաներում։ Եվ վերջապես, ծանր dashboard-ները դրեք read replica-ի կամ ամփոփ աղյուսակների վրա, որպեսզի հաշվետվությունները թարմացնող մենեջերը երբեք չդանդաղեցնի checkout-ը։

• Log արեք admin-ի դանդաղ query-ները և վերանայեք դրանք ամեն ամիս։
• Export-ների և infinite scroll-ի համար նախընտրեք cursor pagination։
• Eager-load արեք ցուցակի սյունակներում օգտագործվող relation-ները։

10Admin մակերեսի պաշտպանություն

Admin-ը բիզնես մտնելու ամենահզոր դուռն է, ուստի արժանի է ամենաուժեղ կողպեքներին։ Յուրաքանչյուր admin account-ի համար պահանջեք երկրորդ factor։ Admin session-ները պահեք կարճ՝ idle timeout-ով, և կրիտիկական գործողություններից առաջ, ինչպիսիք են դերերի կամ payout-ի տվյալների փոփոխությունը, պահանջեք կրկնակի նույնականացում։ Մտածեք admin-ը առանձին subdomain-ով մատուցելու մասին՝ ավելի խիստ cookie-ներով և, որտեղ գործնական է, IP allowlist-ով կամ VPN-ով։ Պաշտպանվեք CSRF-ից cookie-ի վրա հիմնված session-ներում և rich-text դաշտերից եկող stored XSS-ից՝ HTML-ը սերվերում sanitize անելով tag-երի allowlist-ով։ Upload արված ֆայլերը երբեք չպետք է կատարելի լինեն. պահեք դրանք web root-ից դուրս կամ object storage-ում և օգտատերերի upload արած SVG-ն մատուցեք զգուշությամբ, որովհետև SVG-ն կարող է script-ներ պարունակել։ Հետևեք admin login-ներին և alert ստացեք նոր սարքերի կամ impossible travel-ի դեպքում։