AEM 구성 요소와 템플릿은 매우 강력한 툴킷을 구성합니다. 개발자가 웹 사이트 비즈니스 사용자, 편집자 및 관리자에게 사이트의 균일한 레이아웃(브랜드 보호)을 유지하면서 변화하는 비즈니스 요구 사항(콘텐츠 민첩성)에 맞게 웹 사이트를 조정할 수 있는 기능을 제공하는 데 사용할 수 있습니다.
웹 사이트 또는 웹 사이트 집합(예: 글로벌 기업의 지사)을 담당하는 사람의 일반적인 과제는 웹 사이트에 새로운 유형의 컨텐츠 프레젠테이션을 도입하는 것입니다.
이미 게시된 다른 문서에서 추출한 웹 사이트를 나열하는 뉴스 목록 페이지를 웹 사이트에 추가해야 한다고 가정해 보겠습니다. 페이지는 나머지 웹 사이트와 동일한 디자인 및 구조를 가져야 합니다.
이러한 문제에 접근하는 권장 방법은 다음과 같습니다.
이는 이 접근 방식을 통해 웹 사이트의 기여 사용자 및 관리자가 개발 팀의 개입 없이 비즈니스 요구에 신속하게 대응할 수 있는 방법을 보여 줍니다. 새 템플릿 작성과 같은 대체 방법은 일반적으로 비용이 많이 드는 작업이므로 변경 관리 프로세스와 개발 팀의 참여가 필요합니다. 이렇게 하면 전체 프로세스가 훨씬 길어지고 비용이 많이 듭니다.
따라서 AEM 기반 시스템의 개발자는 다음을 사용해야 합니다.
개발자를 위한 다음과 같은 일반 규칙은 대부분의 일반 프로젝트에서 사용할 수 있습니다.
자체 구성 요소를 만들거나 기존 구성 요소를 사용자 정의할 때 기존 정의를 다시 사용하는 것이 가장 쉽고 안전한 경우가 많습니다. 동일한 원칙은 AEM 내의 다른 요소(예: 오류 핸들러)에도 적용됩니다.
이는 기존의 정의를 복사하고 오버레이하여 수행할 수 있다. 즉, 정의 복사 위치 /libs
끝 /apps/<your-project>
. 에서 이 새로운 정의 /apps
는 요구 사항에 따라 업데이트할 수 있습니다.
다음을 참조하십시오 오버레이 사용 을 참조하십시오.
예:
여기에는 구성 요소 정의 오버레이가 포함됩니다.
에서 새 구성 요소 폴더 만들기 /apps/<website-name>/components/<MyComponent>
기존 구성 요소를 복사하여:
예를 들어 텍스트 구성 요소 사본을 사용자 정의하려면 다음을 수행합니다.
/libs/foundation/components/text
/apps/myProject/components/text
이 경우 서블릿 오버레이가 포함됩니다.
저장소에서 기본 스크립트를 복사합니다.
/libs/sling/servlet/errorhandler/
/apps/sling/servlet/errorhandler/
본인 은(는) 해서는 안 됨 의 모든 항목 변경 /libs
경로.
이는 의 콘텐츠가 /libs
는 다음에 인스턴스를 업그레이드할 때 덮어쓰기됩니다(또한 핫픽스 또는 기능 팩을 적용할 때 덮어쓰기될 수도 있음).
구성 및 기타 변경 사항의 경우:
/libs
끝 /apps
/apps
JCR 쿼리는 올바르게 사용할 경우 강력한 도구입니다. 적합한 용도:
콘텐츠에 대한 전체 텍스트 검색과 같은 실제 최종 사용자 쿼리
전체 저장소에서 구조화된 컨텐츠를 찾아야 하는 경우.
이러한 경우, 구성 요소 활성화 또는 캐시 무효화와 같이 절대적으로 필요한 경우에만 쿼리가 실행되도록 합니다(예: 워크플로 단계, 콘텐츠 수정 시 트리거되는 이벤트 핸들러, 필터 등과 달리).
JCR 쿼리는 순수 렌더링 요청에 사용해서는 안 됩니다. 예를 들어 JCR 쿼리는 다음에 적합하지 않습니다.
콘텐츠를 렌더링하려면 JCR 쿼리를 수행하는 대신 콘텐츠 트리에 대한 탐색 액세스를 사용하십시오.
를 사용하는 경우 Query BuilderQuery Builder가 후드에서 JCR 쿼리를 생성하므로 JCR 쿼리를 사용합니다.
또한 을(를) 참조하는 것이 좋습니다. 보안 검사 목록.
관리 세션이 아닌 사용자 세션을 사용해야 합니다. 즉, 다음을 사용해야 합니다.
slingRequest.getResourceResolver().adaptTo(Session.class);
XSS(크로스 사이트 스크립팅)를 사용하면 공격자가 다른 사용자가 본 웹 페이지에 코드를 삽입할 수 있습니다. 이 보안 취약성은 악의적인 웹 사용자가 액세스 제어를 우회하기 위해 악용될 수 있습니다.
AEM은 출력 시 사용자가 제공한 모든 콘텐츠를 필터링하는 원칙을 적용합니다. XSS 예방은 개발 및 테스트 모두에서 가장 높은 우선순위가 부여됩니다.
또한 다음과 같은 웹 애플리케이션 방화벽도 apache용 mod_security를 사용하면 배포 환경의 보안을 안정적으로 중앙에서 제어할 수 있으며 이전에 탐지되지 않은 교차 사이트 스크립팅 공격으로부터 보호할 수 있습니다.
AEM과 함께 제공된 예제 코드는 그 자체로 이러한 공격으로부터 보호되지 않을 수 있으며 일반적으로 웹 애플리케이션 방화벽에 의한 요청 필터링에 의존합니다.
XSS API 치트 시트 에는 XSS API를 사용하고 AEM 앱을 보다 안전하게 만들기 위해 알아야 하는 정보가 포함되어 있습니다. 여기에서 다운로드할 수 있습니다.
XSSAPI 치트 시트.
모든 인터넷 응용 프로그램의 경우 기밀 정보를 전송할 때 다음을 확인하십시오
이는 시스템에 대해 기밀인 정보(예: 구성 또는 관리 액세스)와 해당 사용자에 대해 기밀인 정보(예: 개인 정보)에 적용됩니다
AEM에 대해 오류 페이지를 사용자 지정할 수 있습니다. 인스턴스가 내부 서버 오류에 대한 슬링 추적을 표시하지 않도록 하는 것이 좋습니다.
다음을 참조하십시오 오류 핸들러로 표시된 오류 페이지 사용자 지정 전체 세부 정보.
AEM은 많은 수의 파일에 액세스할 수 있으므로 java 프로세스용 파일 열기 AEM에 대해 명시적으로 구성되어야 합니다.
이 문제를 최소화하려면 개발을 통해 열려 있는 파일이 가능한 한 빨리(의미 있게) 올바르게 닫히도록 해야 합니다.