Insights / Technische Beiträge

Benutzer-CSS und öffentliche Themes sicher verwalten: gemeinsame Quelle, begrenztes Rendering und feste Versionen

Ein anonymisiertes Profilbearbeitungskonzept, in dem GUI und direkte Bearbeitung dieselbe CSS-Quelle nutzen. Behandelt werden eine umfangreiche CSS-Syntax innerhalb einer Rendering-Grenze, Entwürfe und veröffentlichte Fassungen, unveränderliche Theme-Versionen, Auslistung und betriebliche Sperre.

  • CSS
  • Security
  • Web
Benutzer-CSS und öffentliche Themes sicher verwalten: gemeinsame Quelle, begrenztes Rendering und feste Versionen
Inhaltsverzeichnis
  1. Gestaltungsfreiheit und Verteilung getrennt wählen
  2. Eine gemeinsame CSS-Quelle für GUI und direkte Bearbeitung verwenden
  3. Umfangreiche CSS-Syntax innerhalb der Rendering-Grenze unterstützen
  4. Vorschau, Entwurf und Veröffentlichung trennen
  5. Aktive Designs nicht durch Änderungen anderer Autoren verändern
  6. Auslistung und betriebliche Sperre unterscheiden
  7. Was vor der Veröffentlichung zu prüfen ist

Ein Profil-Editor, in dem sich Farben und Abstände über eine grafische Oberfläche anpassen und das gesamte Layout mit CSS bearbeiten lassen, muss sowohl die Bedienbarkeit als auch die Sicherheit des auf öffentlichen Seiten angezeigten Codes berücksichtigen. Dieser anonymisierte Implementierungsfall zeigt die Grenzen zwischen Bearbeitung und Verteilung.

Gestaltungsfreiheit und Verteilung getrennt wählen

Prüfen Sie bei persönlicher Bearbeitung zuerst Bereichsbegrenzung und Speicherkonflikte. Verteilung erfordert zusätzlich feste Versions-IDs, Nutzungsbedingungen und Standarddarstellung nach Sperre. Testen Sie mit Grid und Pseudoelementen, dass äußere Navigation unverändert bleibt und Autoren-Updates angewandte Versionen nicht ersetzen.

W3C Selectors:Geltungsbereich von Selektoren prüfen

Eine gemeinsame CSS-Quelle für GUI und direkte Bearbeitung verwenden

Bei einer späteren Erweiterung wurde das vollständige CSS zur maßgeblichen Theme-Quelle, und die GUI wurde so geändert, dass sie dieselben CSS-Deklarationen bearbeitet. Von Hand geschriebene Kommentare, Deklarationen außerhalb der GUI-Steuerung und responsive Regeln bleiben erhalten. Das ältere Format mit GUI-Einstellungen und zusätzlichem CSS wird ebenfalls in ein vollständig bearbeitbares Stylesheet übernommen. Eine Änderung an Hilfseinstellungen für die Darstellung einer Optionsliste bedeutet nicht, dass sich das gerenderte CSS geändert hat.

Die Erweiterungen für Backend und Frontend wurden jeweils in ihren main-Zweig integriert; CI und Implementierungstests wurden geprüft. Innerhalb dieses Prüfbereichs belegt das weder die Bereitstellung in Produktion noch einen durch angemeldete Nutzer getesteten vollständigen Ablauf.

Umfangreiche CSS-Syntax innerhalb der Rendering-Grenze unterstützen

Die anfängliche Beschränkung durch eine kleine Liste erlaubter Eigenschaften wurde erweitert. Unterstützt werden Grid und Flex, Variablen, Verläufe, Pseudoelemente, Transformationen, Animationen und Regeln wie @media, @supports und @container. Das bedeutet nicht, dass beliebiges CSS ungeprüft eingefügt wird. Der Syntaxbaum wird analysiert, und jeder Selektorzweig wird auf Nachfahren des festgelegten Profilbereichs beschränkt. Dieselbe Grenze gilt innerhalb bedingter Regeln; externe Bedienwege und Lizenzkennzeichnungen gehören nicht zum Theme-Bereich. W3C Selectors ist ein Einstieg in die Selektorspezifikation.

Variablen- und Keyframe-Namen werden im veröffentlichten CSS in eindeutige Namen umgeschrieben, damit sie nicht mit Variablen der äußeren Oberfläche oder Animationen anderer Themes kollidieren. Die ursprünglichen Namen bleiben für die Bearbeitung erhalten. Der äußere Rendering-Wrapper nutzt zusätzlich Containment und Isolation, um die Wirkung weit gefasster Layoutregeln auf den Profilbereich zu begrenzen.

Das Abrufen externer Ressourcen, globale Regeln wie @import und @font-face, nicht analysierbare Syntax, CSS-Nesting, der HTML-Abschluss des style-Elements und Animationsreferenzen mit nicht sicher auflösbaren Namen werden abgewiesen. Auch die Größe der Eingabe und des erzeugten Ergebnisses wird geprüft. Bei der Veröffentlichung und beim Laden eines Snapshots werden Bereich, eindeutige Namen und die validierte kanonische CSS-Zeichenfolge erneut auf Übereinstimmung geprüft. Umfangreiche Syntaxunterstützung garantiert nicht dieselbe Darstellung in jedem Browser.

Vorschau, Entwurf und Veröffentlichung trennen

Das Ausprobieren oder Anwenden eines Themes ändert einen Entwurf. Die öffentliche Seite ändert sich erst, wenn der Eigentümer veröffentlicht. Dass handgeschriebenes CSS erneut bearbeitet werden kann, bedeutet nicht, dass der Originaltext an Besucher weitergegeben wird. Der Speichervertrag erkennt Konflikte und verhindert, dass ein wiederholter Vorgang eine Version oder einen Entwurf doppelt aktualisiert.

Aktive Designs nicht durch Änderungen anderer Autoren verändern

Bearbeitbare Angaben im Theme-Eintrag werden von unveränderlichen Versionen getrennt. Ein Nutzer importiert eine bestimmte Versions-ID; eine neue Version des Autors ändert bestehende Entwürfe und veröffentlichte Fassungen nicht automatisch. Herkunft und Version der angewendeten Theme-Fassung sowie die Quelle der Nutzungsbedingungen bleiben auch nach der Bearbeitung erhalten. Wird ein öffentliches Profil wieder privat, dürfen Name und Bild aus dem Autorenentwurf nicht in das verteilte Theme gelangen.

Auslistung und betriebliche Sperre unterscheiden

Wenn ein Autor ein Theme auslistet, sind neue Entdeckungen und Anwendungen nicht mehr möglich; bestehende Nutzungen einer festgelegten Version werden dadurch nicht zwingend sofort widerrufen. Die betriebliche Sperre eines gefährlichen Themes hat eine andere Grenze: Öffentlicher Abruf und CSS aus bestehenden Snapshots werden gestoppt, und die Standarddarstellung wird wiederhergestellt. Auch bei einem Rollback auf einen älteren Snapshot wird der aktuelle Sperrstatus geprüft, damit CSS von vor der Sperre nicht wieder aktiviert wird.

Von der CSS-Bearbeitung zur festen Version Codeintegration, CI und Produktivbereitstellung der früheren Store-Version wurden geprüft. Produktiv-/Login-Abnahme der CSS-Erweiterung, Nutzeranwendung und kostenpflichtige Verkäufe sind unbestätigt.
  1. Gemeinsame CSS-Quelle GUI und direkte Bearbeitung nutzen dieselbe CSS-Quelle und erhalten handgeschriebene Regeln.
  2. Analysieren und begrenzen Unterstützt Grid/Flex, Variablen, Pseudoelemente, responsive Regeln und Animation. Externe, globale oder nicht analysierbare Eingaben werden abgelehnt.
  3. Version ausdrücklich veröffentlichen Nach Vorschau/Entwurf eine unveränderliche Version veröffentlichen. Auslistung und betriebliche Sperre sind getrennt.

Was vor der Veröffentlichung zu prüfen ist

Prüfe Selektoren außerhalb des Bereichs, externe Anfragen, Eingabegröße, Speicherkonflikte, Wiederholungen, das Umstellen des Autorenprofils auf privat, Auslistung, betriebliche Sperre und Rollback. Die Produktionsbereitstellung des Stores mit festen Versionen und die Darstellung mit Testdaten wurden bestätigt. Innerhalb dieses Prüfbereichs sind jedoch weder die Produktionsbereitstellung noch die Abnahme mit angemeldeten Nutzern für die CSS-Editor-Erweiterung bestätigt. Bei einer früheren Prüfung gab es null öffentliche Themes; das ist keine Aussage über die aktuelle Zahl. Ein vollständiger Ablauf, in dem echte Nutzer Themes einreichen und anwenden, sowie kostenpflichtige Verkäufe wurden nicht nachgewiesen. Nutzungsbedingungen können nicht garantieren, dass CSS, das einen Browser erreicht, niemals kopiert wird.

Zum Eingabeteil der Bearbeitung siehe Profilinformationen als Entwurf importieren; zu CMS-Abläufen siehe den Sveltia-CMS-Leitfaden.