pacod-cms

Един стек, много сайтове

pacod-cms обслужва много сайтове на много организации от един стек. Всеки сайт има собствена MongoDB база данни, собствена папка с файлове и собствени записи в кеша и отговаря на хостовете, които заявява. Всеки, който се регистрира, може да създаде организация, да стане неин администратор, да създава сайтове в нея и да кани хора да работят по тях; администратор на платформата задава лимитите.

Дизайнът изхожда от това, че собственикът на един сайт може да е враждебен към всички останали в инсталацията. Сайтовете изпълняват скриптове, написани от собствениците им — HTML5 банери, таг мениджъри, текстове на статии, — и платформата трябва да държи тези скриптове и тези данни там, където им е мястото.

Как се свързват частите

Двете приложения никога не се извикват едно друго. И двете работят директно с MongoDB, така че редакция в студиото стига до публичния сайт през базата данни; кешовете на сайта изтичат след 60 секунди, вместо да бъдат изчиствани, така че редакцията е видима до минута.

От хоста до страницата

Всяка единица работа принадлежи на точно един сайт, обвързан с нея за цялото ѝ времетраене.

1. Caddy предава заявката на сайта. В продукция Caddy поисква сертификата на сайт при първото посещение, но едва след като сайтът потвърди, че хостът принадлежи на активен сайт.
2. Сайтът търси хоста в контролната равнина, преди да се изпълни каквото и да е друго. Хост, който не е заявен от активен сайт, получава обикновен 404, никога сайт по подразбиране.
3. При обвързан сайт всяка операция с MongoDB отива в базата данни на този сайт. Ако няма обвързан сайт, слоят за данни хвърля грешка, вместо да гадае.
4. Оформлението на типа страница — области с подредени секции — се разрешава спрямо набора шаблони на сайта, а данните на всяка секция се зареждат предварително. Шаблоните никога не правят заявки; секция, чиито данни не се заредят, се пропуска и записва в лога, а страницата пак се изобразява.

В студиото сайтът се определя от пътя (/sites/<id>/mgmt/…); фоновата работа обвързва сайта, за който се изпълнява.

Къде живеят данните

Идентичността на сайта — име, лога, данни за контакт, идентификатори на трети страни — е данни, а не маркировка. Идентификатор на трета страна се изобразява само когато е зададен и има формата на своя доставчик, така че нов сайт не зарежда никакво проследяване. Оригиналният език на съдържанието на сайта е последният резервен вариант при липсващ превод и юридически валидният текст.

Дизайн без писане на код

В раздела Дизайн на студиото всеки сайт избира набор шаблони — editorial, списание с колона до съдържанието, или minimal, една спокойна колона — и подрежда оформление за всеки тип страница: начална, статия, категория, най-нови, постоянна страница и търсене. Сред секциите са списъци със статии (най-новите, от категория или най-четените), форматиран текст, призив за действие, поле за търсене и връзките към социалните мрежи. Темата задава цветове със стойности за нощен режим, шрифтове и ширини.

Смяната на набора първо показва какво ще се загуби, и нищо не се премахва: секциите, които новият набор не може да покаже, се запазват и се връщат при обратна смяна. Оформленията и темата остават чернови, докато някой с право да ги публикува не го направи. Прегледът показва черновите от собствения адрес на сайта, в ширина за компютър, таблет или телефон, чрез подписан токен, валиден 30 минути, и не отчита нищо.

Нов набор шаблони е код, който операторът инсталира, а не качен файл: шаблон на Thymeleaf може всичко, което може и сайтът.

PDF файлове и броеве на списание

Дългата работа се изпълнява в студиото като задача, по една организация наведнъж, с лог на живо и бутон за отказ. Експортът в PDF е такава задача: Gotenberg превръща всяка статия в по един PDF за всеки език, на който е написана, а статията сочи своя PDF, щом той съществува.

• Два формата. Стандартният е изгледът за печат на сайта. Научният е оформление на научна статия: заглавна част на цялата ширина със заглавието, авторите, резюмето и ключовите думи, след това текстът в две колони.
• Два начина на изготвяне. Само с код взема резюмето и ключовите думи от описанието и таговете на статията. С AI възлага на pacod-gw да напише резюме, ключови думи и кратко заглавие за колонтитула за всяка статия и всеки език. Текстът на статията никога не се променя.
• Настройките за PDF съдържат стойностите по подразбиране на всеки сайт: формат и начин, хартия (A4, Letter или A5) и полета, името на списанието за всеки език и неговия ISSN, колонтитул и номера на страниците. Всяко изпълнение може да избере друг формат и начин.

Брой на списание събира статии в по един PDF за всеки език. Той има том, номер и месец, заглавие и уводна статия за всеки език и по желание изображение за корица; статиите му се избират една по една или се попълват от месеца му, след което се подреждат. При генериране се изготвят корица, уводната статия, съдържание с номера на страниците и след това статиите, с отметка за всяка статия и последователна номерация на страниците. PDF файловете на брой в чернова се изтеглят само от студиото. Публикуването поставя броя и неговите PDF файлове на сайта под /issues и в картата на сайта.

Модел на сигурността

Кой какво може

pacod-id притежава акаунтите и ролите. Токените не носят роли: студиото следи потока с присвоени роли на pacod-id и само решава всяко разрешение спрямо манифеста на CMS (authz/cms.yaml). Ролите са администратор на платформата, провижънър, администратор на организация, администратор на сайт, дизайнер, редактор, автор и анализатор, присвоени на ниво платформа, организация или сайт. Авторът пише; редакторът също и публикува.

• Всеки обработчик в студиото декларира разрешението, от което се нуждае; такъв, който не декларира нищо, се отказва. Никоя роля не е неявна.
• Когато потокът на pacod-id не е отговарял една минута, студиото връща 503, вместо да решава с роли, които може вече да са отнети. Публичните сайтове не са засегнати.

Сайтовете остават разделени

• Студиото е на различен регистрируем домейн от сайтовете, иначе отказва да стартира. В противен случай скрипт на сайт би могъл да задава бисквитки за студиото и да обезсили защитата му от CSRF.
• Студиото никога не сервира HTML или скриптове на сайт. Прегледите на чернови и на HTML5 банери се вграждат от собствения произход (origin) на сайта.
• Gotenberg е изолиран: достига само вътрешния адрес на сайта и не изпълнява JavaScript.
• До читателя стигат само публикувани статии — по всеки маршрут, във всеки списък, поток, карта на сайта и PDF. Брой на списание в чернова никога не е публичен.

AI, който не пипа ключовете ви

Всяко извикване на AI минава през pacod-gw; студиото никога не държи ключ на доставчик. За нови организации AI е изключен по подразбиране: администратор на платформата го включва за всяка организация, а администраторът на сайт може да го изключи за своя сайт.

• Преводът на статии се изпълнява като задача. Преведеният текст трябва да запази точно маркировката на оригинала — може да се променят само alt, title, aria-label и placeholder, — иначе се отхвърля.
• Преводът на сайта обхваща постоянните страници, имената на раздели, менютата, страницата с връзки и, ако е отметнато, таговете, без да презаписва редакция, направена по време на изпълнението; най-много 2000 извиквания на изпълнение.
• Помощта при писане преформулира избран текст по шест начина и предлага резюме и тагове.
• Алтернативен текст за всеки език предлага модел за изображения въз основа на самата картина.
• Асистентът за дизайн изготвя тема или оформление по няколко думи и записва само в черновата.
• Заглавната част на PDF: за PDF файлове, изготвени с AI, резюме, ключови думи и заглавие за колонтитула за всяка статия и всеки език, проверени като обикновен текст. Използват се отново, докато статията не бъде редактирана.

Гейтуеят вижда само непрозрачни идентификатори, никога имена или имейл адреси.

Три среди, един Makefile

Stage е конфигурацията на продукцията, с прихваната поща и симулиран AI. make check отказва стартиране, докато липсва тайна или конфигурацията е несигурна. Правете резервни копия на .env, базите данни в MongoDB, файловете на сайтовете и PostgreSQL на pacod-id. /mgmt-health на студиото проверява само дали то работи: студио, което не достига pacod-id, остава „здраво“, докато екраните му връщат 503, и съобщава за това в лога си.

Всяка среда работи в pacod-net, Docker мрежата, която всички проекти на pacod споделят. Собствените услуги на CMS — сайтът, студиото, MongoDB и Gotenberg — са в един compose файл; собствените му копия на споделените части — Caddy, pacod-id с неговия PostgreSQL, гейтуеят за разработка и прихващачът на поща — са във втори, който Makefile зарежда заедно с първия. На една машина се побира само един стек, който изпълнява споделените части. pacod-demo зарежда само първия файл и изпълнява CMS заедно с другите проекти зад един Caddy, един pacod-id, един PostgreSQL и един гейтуей; той е достъпен на demo.pacod.io.

Ограничения и още за четене

Известни ограничения във v1:

• Идентичността на сайта (siteSettings) все още няма екран в студиото; редактира се в базата данни.
• Демо съдържанието е само на английски.
• Списъкът с членове не показва роли на ниво платформа.

Пътната карта изброява какво v1 отлага, сред тях API за запис, ключ за гейтуея и бюджет за AI за всяка организация, отделен работен процес, хранилище S3 и импорт на съдържание.

В хранилището:

• Архитектура — как заявката намира своя сайт
• Сигурност — какво разделя сайтовете и студиото
• Набори шаблони — как да напишете собствен набор
• Стартиране и Внедряване — среди, TLS, хостове, настройки
• Пътна карта — какво включва v1 и какво е отложено