Du visar hjälpinnehåll för version:
- 6.4
- 6.3
- 6.2
- Äldre versioner
Closed User Groups (CUGs) are used to limit access to specific pages that reside within a published internet site. Such pages require the assigned members to login and provide security credentials.
To configure such a area within your website you:
- create the actual closed user group and assign members.
- apply this group to the required pages and select (or create) the login page for use by the members of the CUG; also specified when applying a CUG to a content page.
- create a link, of some form, to at least one page within the protected area, otherwise it will not be visible.
- configure the Dispatcher if in use.
Viktigt:
Closed user groups (CUGs) should always be created with performance in mind.
Although the number of users and groups in a CUG is not limited, a high number of CUGs on a page may slow down rendering performance.
The impact of CUGs should always be considered when doing performance testing.
-
Obs!
See Managing Users and Groups for full information on creating and configuring users and groups.
See Identity Management for information about profiles in the publish environment and providing forms for logging in and out.
Since the target of any links to the CUG Realm are not visible to the anonymous user, the linkchecker will remove such links.
To avoid this, it is advisable to create non-protected redirect pages that point to pages within the CUG Realm. The navigation entries are then rendered without causing the linkchecker any problems. Only when actually accessing the redirect page will the user be redirected inside the CUG Realm - after successfully providing their login credentials.
You need to configure the Sling Referrer Filter with all hostnames that may be used to access AEM; for example, via CDN, Load Balancer, and any others.
If the referrer filter is not configured, then the following error is seen when a user tries to log in to a CUG site:
31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : http://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown
If you are using Dispatcher, you need to define a Dispatcher farm with the following properties:
- virtualhosts: Matches the path to the pages that the CUG applies to.
- \sessionmanagement: see below.
- cache: A cache directory that is dedicated to the files that the CUG applies to.
Configure session management in the dispatcher.any file for the CUG. The authentication handler that is used when access is requested for CUG pages determines how you configure session management.
For example, the default CRX login module uses token-based authentication, and sets a cookie named login-token. In this case, the /sessionmanagement configuration section requires aheader parameter that identifies the cookie:
/sessionmanagement
...
/header "Cookie:login-token"
...
Obs!
When a Dispatcher farm has session-management enabled, all pages that the farm handles are not cached. To cache pages that are outside of CUG, create a second farm in dispatcher.any
that handles the non-CUG pages.
-
Configure /sessionmanagement by defining /directory; for example:
/sessionmanagement { /directory "/usr/local/apache/.sessions" ... } -
Set /allowAuthorized to 0.
Twitter™- och Facebook-inlägg omfattas inte av villkoren i Creative Commons-licensen.