Teraz z AI - twórz strony przez serwer MCP

Konto

Co daje Twój plan, które limity są egzekwowane i jak role decydują, kto co może.

Workspace niesie plan, zestaw limitów i listę członków. Wszystkie trzy da się odczytać programowo, więc warto je zrozumieć, zamiast odkrywać w złym momencie.

Plan i limity

Każdy workspace raportuje swój plan i pułapy, które z niego wynikają:

{
  "name": "Acme",
  "slug": "acme",
  "plan": "enterprise",
  "limits": {
    "maxPages": 999999,
    "maxMembers": 999999,
    "maxWorkspaces": 999999,
    "maxStorageMb": 999999,
    "maxAiTokensMonth": 999999,
    "maxApiRequestsMonth": 999999999,
    "maxBandwidthGbMonth": 999999,
    "canRemoveBranding": true,
    "canUseCart": true
  }
}

Te liczby pochodzą z workspace'u enterprise, gdzie pułapy są ustawione tak wysoko, że są praktycznie nielimitowane. Mniejsze plany zwracają realne wartości - i o to chodzi, żeby je odczytywać, a nie zaszywać założenie w kodzie.

Mieszkają tam dwa rodzaje rzeczy. Pułapy - strony, członkowie, storage, tokeny AI, requesty API, transfer - to ilości, które możesz wyczerpać. Flagi możliwości - canRemoveBranding, canUseCart - to funkcje włączone albo wyłączone.

Odczytuj je, zamiast zakładać. Krok builda tworzący strony albo skrypt wgrywający media hurtem powinien wiedzieć, pod jakim pułapem pracuje.

Limit delivery pada w mylący sposób

Przekrocz miesięczny limit dostarczania, a public.siteConfig przestaje odpowiadać. Twój serwis zachowuje się wtedy dokładnie tak, jakby slug workspace'u był zły albo sieć leżała.

Dlatego preflight w cmssy link rozróżnia te trzy przypadki, zamiast raportować jedno "nie mogę dosięgnąć workspace'u". Jeśli Twój serwis nagle nic nie pobiera, a w konfiguracji nic się nie zmieniło, sprawdź zużycie, zanim sprawdzisz DNS.

Role

Uprawnienia mają przestrzeń nazw zasób:akcja - pages:view, media:upload, forms:submissions:manage, workspace:billing. Rola to nazwana wiązka takich uprawnień.

Role niosą dwie flagi warte poznania:

  • isSystem - wbudowana i nieedytowalna. Owner jest rolą systemową i trzyma *: każde uprawnienie, w tym przyszłe. Ten wildcard jest sensem - nowa funkcja nie wymaga aktualizacji roli właściciela.
  • isDefault - rola, którą dostają nowi członkowie. Ustaw ją świadomie; to, co trzyma, jest tym, co daje zaproszenie, zanim ktokolwiek je przejrzy.

Role zespołu i role członków to różne rzeczy

Workspace może trzymać rolę bez żadnych uprawnień - zwykle nazwaną czymś w rodzaju Customer. To nie jest błąd konfiguracji.

Członkowie serwisu, którzy logują się na Twojej publicznej stronie, to co innego niż ludzie, którzy ją edytują. Rola członka istnieje po to, żeby etykietować i grupować tych odwiedzających; nie daje niczego w workspace, bo klient Twojego sklepu nie ma czego szukać w Twoim CMS-ie. Role zespołu nadają uprawnienia w workspace; role członków identyfikują odbiorców.

Pomylenie tych dwóch to sposób, w jaki rola klienta po cichu dostaje pages:edit.

Granularność jest celowa

Lista uprawnień rozdziela rzeczy, których możesz spodziewać się razem. pages:edit i pages:publish są osobne - możesz pozwolić komuś pisać, nie pozwalając wypuszczać. forms:view i forms:submissions:view są osobne - zbudowanie formularza kontaktowego nie wymaga czytania tego, co ludzie przez niego wysłali.

Traktuj ten podział poważnie przy składaniu ról. Domyślną pokusą jest rozdawanie całych przestrzeni nazw, a w momencie gdy to zrobisz, "może edytować teksty" i "może czytać wiadomości od klientów" stają się tym samym nadaniem.

Następne kroki