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 ma własnych członków i role; plan oraz limity bierze z organizacji, do której należy. Wszystkie trzy da się odczytać programowo, więc warto je zrozumieć, zamiast odkrywać w złym momencie.

Plan i limity

Plan siedzi na organizacji, nigdy na pojedynczym workspace, a zużycie jest współdzielone przez wszystkie workspace'y tej organizacji - dodanie workspace'u nie dodaje kwoty. get_workspace_info raportuje plan i pułapy obowiązujące dla workspace'u, czyli te należące do jego organizacji:

{
  "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 organizacji na planie 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. Czytaj je jako wspólne: drugi workspace czerpie z tej samej puli, nie z nowej.

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