Individual visitors to your website can only be identified when you provide the ability for them to log in. There are various reasons why you may want to provide a login capability:
- AEM Communities
Site visitors are required to sign in to post content to the community.
- Closed User Groups
You may need to limit access to your website (or sections of it) to specific visitors.
Allowing visitors to configure certains aspects of how they access your website.
Log in (and out) functionality is provided by an account with a Profile, which holds additional information about the registered visitor (user). The actual processes for registration and authorization may differ:
- Self-registration from the website
A Community Site may be configured to allow visitors to self-register or sign-in with their Facebook or Twitter accounts.
- Request for registration from the website
For a closed user group you might allow visitors to request registration, but enforce authorization by means of a workflow.
- Register each account from the author environment
If you have a small number of profiles, which will need authorization anyway, you may decide to register each directly.
To allow visitors to register, a series of components and forms can be used to collect the required identification information, then the additional (often optional) profile information. After they have registered, they should also be able to check and update, the details that they have submitted.
Additional functionality can be configured or developed:
- Configure any reverse replication that is required.
- Allow a user to remove their profile, by developing a form together with a workflow.
A form can be used to collect the registration information, then generate the new account and profile.
For example, users can request a new profile, using the Geometrixx page
The new account is also visible in the Users console.
The login component can be used to collect the login information, then activate the login process.
This provides the visitor with the standard fields of Username and Password, with a Login button to activate the login process when the credentials are entered.
For example, users can either log in, or create a new account, using the Sign In option on the Geometrixx toolbar, which uses the page:
As there is a login mechanism, a logout mechanism is also required. This is available as the Sign Out option in Geometrixx.
Depending on your registration form the visitor may have registered information in their profile. They should be able to view and/or update this at a later stage. This can be done with a similar form; for example, in Geometrixx:
To see the details of your profile click on My Profile in the top right corner of any page; for example with the admin account:
You can view another profile using the client context (on the author environment and with sufficient privileges):
You can add fields to the profile definition. For example to add a "Favorite Color" field to the Geometrixx profile:
There are a number of use cases that require knowing whether a user (or rather their profile) is in a specific state or not.
This involves defining an appropriate property in the user profile in a way that:
- is visible and accessible to the user
- defines two states for each property
- allows toggling between the two states defined
Multiple states can be defined; for example in Geometrixx these include:
- subscribing (or unsubscribing) to notifications on newsletters or comment threads
- adding and removing a connection to a friend
A state provider manages the current state of the property in question, together with the transitions between the two possible states.
State providers are implemented as components, so can be customized for your project. In Geometrixx these include:
- Un-/Subscribe Forum Topic
- Add/Remove Friend
State providers manage a profile property and its states.
A workflow is needed to implement the actions related to the states. For example, when subscribing for notifications, the workflow will handle the actual subscription action; when unsubscribing from notifications, the workflow will handle removing the user from the subscription list.
Profiles are stored in the Content Repository as part of the the user account.
On a standard installation (author or publish) everyone has read access to the entire profile information of all users. everyone is a "Built-in group automatically containing all existing users and groups. The list of members cannot be edited".
These access rights are defined by the following wildcard ACL:
/home everyone allow jcr:read rep:glob = */profile*
- forum, comments or blog posts to display information (such as icon or full name) from the appropriate profile
- links to geometrixx profile pages
If such access is not appropriate for your installation you can change these default settings.
This can be done using the Access Control tab:
A range of profile components are also available for defining the profile requirements for your site.
This component gives you two fields for:
- the input of a password
- a check to confirm that the password has been input correctly.
With default settings the component will appear as follows: