Im folgenden Abschnitt finden Sie Antworten auf häufig gestellte Fragen (FAQs) zum Screens as a Cloud Service-Projekt.
AEM as a Cloud Service ändert die langen Cache-Schlüssel bei jeder Bereitstellung. AEM Screens generiert die Offline-Caches, wenn der Inhalt geändert wird, und nicht, wenn Cloud Manager die Bereitstellung ausführt. Diese langen Cache-Schlüssel in den Manifesten sind ungültig, sodass der Player die clientlibs.
Verwenden longCacheKey="none"
in clientlib
Ordner entfernt die langen Cache-Schlüssel vollständig für die clientlibs.
Offline-Caches werden mithilfe des Servives bulk-offline-update-screens-service erzeugt. Bestimmte Pfade, auf die von bulk-offline-update-screens-service
nicht zugegriffen werden kann, führen zu fehlenden Inhalten in Offline-Manifesten.
Erstellen Sie in Ihrem Code, d. h. in ui.config or ui.apps
, eine OSGi-Konfiguration im Konfigurationsordner mit folgendem Inhalt, und geben Sie der Datei den Namen org.apache.sling.jcr.repoinit.RepositoryInitializer-serviceusersandacls-content.config
.
scripts=[
"
set principal ACL for bulk-offline-update-screens-service
allow jcr:read on /content/mysite
allow jcr:read on /apps/my-resources
end
"]
Es wird empfohlen, in einem AEM Screens as a Cloud Service-Kanal Bilder im Format .png
und .jpeg
zu verwenden, um ein optimales Digital Signage-Erlebnis zu erzielen.
Bilder im Format *.tif
(Tag-Image-Dateiformat) werden in AEM Screens as a Cloud Service nicht unterstützt. Wenn ein Kanal dieses Bildformat aufweist, wird das Bild auf der Player-Seite nicht gerendert.
Adobe empfiehlt die Verwendung von AEM Screens-Caching-Funktionen. Wenn Sie Ihren Kanal jedoch im Entwicklermodus ausführen müssen und der AEM Screens-Player einen leeren Bildschirm anzeigt, überprüfen Sie die Entwicklertools Ihres Players und suchen Sie nach X-Frame-Options
oder frame-ancestors
Fehler. Die Lösung besteht darin, den Dispatcher so zu konfigurieren, dass Inhalte in iFrames ausgeführt werden können. Normalerweise funktioniert die folgende Konfiguration:
Header set Content-Security-Policy "frame-ancestors 'self' file: localhost:*;"
Als Best Practice können Sie die Verwendung des Registrierungs-Codes einschränken. Wenn ein Registrierungs-Code kompromittiert ist, aber eine Grenze von 100 Registrierungen hat, kann sich der Angreifer nur bis zu dieser Zahl registrieren, aber nicht häufiger. Sie können die Nutzungsbeschränkung jederzeit aktualisieren, nachdem der Registrierungs-Code erstellt und einige der Player des Kunden bereits registriert wurden. Wenn der Kunde eine ungewöhnliche Registrierungsaktivität für einen bestimmten Registrierungs-Code beobachtet, kann er die Beschränkung in Echtzeit senken, während er untersucht. Sie können die Anzahl wieder erhöhen, wenn es sich um einen falschen Alarm handelt, ohne dass die bereits registrierten Spieler betroffen sind.