A seção a seguir fornece respostas às Perguntas frequentes relacionadas ao projeto do Screens as a Cloud Service.
AEM as a Cloud Service alterações nas chaves de cache longas com cada implantação. O AEM Screens gera os caches offline quando o conteúdo é modificado, em vez de quando o Cloud Manager executa a implantação. Essas chaves de cache longas nos manifestos são inválidas, portanto, o reprodutor não consegue baixá-las clientlibs.
Usando longCacheKey="none"
em seu clientlib
a pasta remove completamente as chaves de cache longas para elas clientlibs.
Os caches offline são gerados usando bulk-offline-update-screens-service usuário do serviço. Determinados caminhos, não acessíveis por bulk-offline-update-screens-service
, levar ao conteúdo ausente em manifestos offline.
No seu código, isto é, ui.config or ui.apps
, crie uma configuração OSGi na pasta de configuração, com o seguinte conteúdo, e nomeie o nome do arquivo como 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
"]
É recomendável usar imagens no formato .png
e .jpeg
em um canal as a Cloud Service AEM Screens, para obter a melhor experiência em sinalização digital.
As imagens no formato *.tif
(Formato de arquivo de imagem de tag) não é compatível com o AEM Screens as a Cloud Service. Caso um canal tenha esse formato de imagem, então, no lado do reprodutor, a imagem não será renderizada.
É recomendável aproveitar os recursos de armazenamento em cache do AEM Screens, mas se você precisar executar seu Canal no modo Desenvolvedor e o AEM Screens Player mostrar uma tela em branco, verificar as ferramentas do desenvolvedor do Player e procurar X-Frame-Options
ou frame-ancestors
erros. A resolução é configurar o dispatcher para permitir o conteúdo em execução no iFrames. Normalmente, a seguinte configuração funcionará:
Header set Content-Security-Policy "frame-ancestors ‘self’ file: localhost:*;"
Como prática recomendada, é possível limitar o uso do código de registro. Se um código de registro estiver comprometido, mas tiver um limite de 100 registros, o invasor poderá se registrar apenas até esse número, mas não mais. Você sempre pode atualizar o limite de uso depois que o código de registro é criado e alguns dos players do cliente já foram registrados. Se o cliente observar uma atividade de registro incomum para um código de registro específico, ele poderá reduzir o limite em tempo real enquanto investiga e aumentar o número novamente se for um alarme falso, sem afetar os players já registrados.