Sviluppo AEM - Linee guida e migliori prassi

Linee guida per l’utilizzo di modelli e componenti

AEM componenti e modelli formano un potente toolkit. Possono essere utilizzati dagli sviluppatori per fornire agli utenti aziendali dei siti Web, agli editor e agli amministratori le funzionalità necessarie per adattare i loro siti Web alle esigenze aziendali in continua evoluzione (agilità dei contenuti), mantenendo al contempo il layout uniforme dei siti (protezione del marchio).

Una tipica sfida per una persona responsabile di un sito Web, o per un insieme di siti Web (ad esempio in una succursale di un'azienda globale), è quella di introdurre un nuovo tipo di presentazione dei contenuti sui propri siti Web.

Supponiamo che sia necessario aggiungere una pagina di newslist ai siti Web, in cui sono elencati estratti di altri articoli già pubblicati. La pagina deve avere la stessa struttura e struttura del sito Web.

Il modo consigliato per affrontare tale sfida sarebbe di:

  • Riutilizzate un modello esistente per creare un nuovo tipo di pagina. Il modello definisce in modo approssimativo la struttura delle pagine (elementi di navigazione, pannelli e così via), ulteriormente regolata dalla sua progettazione (CSS, grafica).
  • Utilizzate il sistema paragrafo (parsys/iparsys) nelle nuove pagine.
  • Consente di definire l'accesso alla modalità Progettazione dei sistemi di paragrafi, in modo che solo gli utenti autorizzati (in genere l'amministratore) possano modificarli.
  • Definite i componenti consentiti nel sistema di paragrafi specificato in modo che gli editor possano quindi posizionare i componenti richiesti sulla pagina. Nel nostro caso potrebbe trattarsi di un componente elenco, che può scorrere una sottostruttura di pagine ed estrarre le informazioni in base a regole predefinite.
  • Gli editor aggiungono e configurano i componenti consentiti, sulle pagine di cui sono responsabili, per fornire le funzionalità richieste (informazioni) all'azienda.

Questo approccio illustra come questo approccio consente agli utenti e agli amministratori del sito Web partecipanti di rispondere rapidamente alle esigenze aziendali, senza richiedere il coinvolgimento di team di sviluppo. Metodi alternativi, come la creazione di un nuovo modello, è in genere un esercizio costoso, che richiede un processo di gestione delle modifiche e il coinvolgimento del team di sviluppo. Ciò rende l'intero processo molto più lungo e costoso.

Gli sviluppatori di sistemi AEM dovrebbero pertanto utilizzare:

  • modelli e controllo dell'accesso alla progettazione del sistema paragrafo per uniformità e protezione del marchio
  • il sistema di paragrafi, comprese le opzioni di configurazione per la flessibilità.

Le seguenti regole generali per gli sviluppatori hanno senso nella maggior parte dei progetti comuni:

  • Mantenete basso il numero di modelli, fino al numero di strutture di pagina fondamentalmente diverse nei siti Web.
  • Offrite ai componenti personalizzati la flessibilità e le funzionalità di configurazione necessarie.
  • Ottimizzate l'utilizzo della potenza e della flessibilità del sistema AEM paragrafi, ovvero i componenti parsys e iparsys.

Personalizzazione di componenti e altri elementi

Quando create componenti personalizzati o personalizzate un componente esistente, è spesso più semplice (e sicuro) riutilizzare le definizioni esistenti. Gli stessi principi si applicano anche ad altri elementi all'interno di AEM, ad esempio il gestore di errori.

È possibile eseguire questa operazione copiando e sovrapponendo la definizione esistente. In altre parole, copiando la definizione da /libs a /apps/<your-project>. Questa nuova definizione, in /apps, può essere aggiornata in base alle tue esigenze.

Nota

Consultate Utilizzo delle sovrapposizioni per ulteriori dettagli.

Ad esempio:

  • Personalizzazione di un componente

    Questo comportava la sovrapposizione di una definizione di componente:

    • Per creare una nuova cartella di componenti, copiate /apps/<website-name>/components/<MyComponent> un componente esistente:

      • Ad esempio, per personalizzare la copia del componente Testo:

        • da /libs/foundation/components/text
        • a /apps/myProject/components/text
  • Personalizzazione delle pagine mostrate dal gestore errori

    Questo caso comporta la sovrapposizione di un servlet:

    • Nell'archivio, copiare gli script predefiniti:

      • da /libs/sling/servlet/errorhandler/
      • a /apps/sling/servlet/errorhandler/
ATTENZIONE

Non devi cambiare nulla nel /libs percorso.

Questo perché il contenuto di /libs viene sovrascritto al successivo aggiornamento dell’istanza (e potrebbe essere sovrascritto quando si applica un hotfix o un feature pack).

Per la configurazione e altre modifiche:

  1. copiate l’elemento in /libs /apps
  2. apportare eventuali modifiche /apps

Quando utilizzare le query JCR e quando non utilizzarle

Le query JCR sono uno strumento potente quando utilizzate correttamente. Sono appropriati per:

  • query reali per l’utente finale, ad esempio ricerche full-text sul contenuto.

  • le occasioni in cui è necessario reperire contenuti strutturati in tutto il repository.

    In tali casi, accertatevi che le query vengano eseguite solo quando è assolutamente necessario, ad esempio in caso di attivazione di un componente o di annullamento della validità della cache (invece di eseguire i passaggi dei flussi di lavoro, i gestori eventi che attivano le modifiche ai contenuti, i filtri, ecc.).

Le query JCR non devono mai essere utilizzate per richieste di rendering pure. Ad esempio, le query JCR non sono adatte a

  • rendering, navigazione
  • creazione di una panoramica delle 10 ultime notizie
  • visualizzazione del numero di elementi di contenuto

Per eseguire il rendering del contenuto, utilizzate l'accesso alla struttura del contenuto invece di eseguire una query JCR.

Nota

Se utilizzate Query Builder, potete utilizzare Query JCR, poiché Query Builder genera Query JCR sotto la cappa.

Considerazioni sulla sicurezza

Nota

È inoltre utile fare riferimento all'elenco di controllo della sicurezza.

Sessioni JCR (repository)

Utilizzate la sessione utente, non quella amministrativa. Questo significa che devi usare:

slingRequest.getResourceResolver().adaptTo(Session.class);

Protect contro lo scripting tra siti (XSS)

Lo scripting tra siti (XSS) consente agli aggressori di inserire codice nelle pagine Web visualizzate da altri utenti. Questa vulnerabilità di sicurezza può essere sfruttata da utenti Web malintenzionati per aggirare i controlli di accesso.

AEM applica il principio di filtraggio di tutti i contenuti forniti dall’utente al momento dell’output. La prevenzione di XSS viene data la massima priorità sia durante lo sviluppo che durante i test.

Inoltre, un firewall per applicazioni Web, come mod_security per Apache, può fornire un controllo centrale affidabile sulla sicurezza dell'ambiente di distribuzione e proteggere contro attacchi di script tra siti non rilevati in precedenza.

ATTENZIONE

Il codice di esempio fornito con AEM potrebbe non essere di per sé protetto da tali attacchi e in genere si basa sul filtraggio delle richieste da parte di un firewall dell'applicazione Web.

Il foglio di controllo API XSS contiene informazioni che è necessario conoscere per utilizzare l'API XSS e rendere un'app AEM più sicura. Potete scaricarlo qui:

Il foglio di imbroglio XSSAPI.

Ottieni file

Comunicazione sicura per informazioni riservate

Per quanto riguarda le applicazioni Internet, assicurarsi che durante il trasporto di informazioni riservate

  • il traffico è protetto tramite SSL
  • POST HTTP, se applicabile

Ciò vale per le informazioni riservate al sistema (come la configurazione o l'accesso amministrativo) e per quelle riservate agli utenti (come i loro dati personali)

Attività di sviluppo distinte

Personalizzazione delle pagine di errore

Le pagine di errore possono essere personalizzate per AEM. Questo è consigliabile in modo che l'istanza non riveli tracce di utilizzo in caso di errori interni del server.

Per informazioni dettagliate, consultate Personalizzazione delle pagine di errore visualizzate dal gestore di errori.

Apri file nel processo Java

Poiché AEM può accedere a un gran numero di file, si consiglia di configurare in modo esplicito per AEM il numero di file aperti per un processo Java.

Per ridurre al minimo questo problema, lo sviluppo dovrebbe garantire che tutti i file aperti vengano chiusi correttamente non appena (significativo) possibile.

In questa pagina