How to design a page having different content for logged in and non-logged in users?

Question

We have a requirement to show different content (few links in header section) on a page for logged in and non-logged in users. URL of the page will remain same for both users.

How to design such pages in AEM. How the caching and validation of users would work on each page requests?

@asutosh_jena_ , @arunpatidar , @markusbullaadobe , @vijayalakshmi_s , @pulkit_jain_ , @vaibhavi_j , @ritesh_mittal

MarkusBullaAdobe · Accepted Answer

Hi @kamal_kishor!

Depending on the exact use case, there are different approaches to this kind of requirement.

1. You have two groups of users (logged-in vs. anonymous)

2. You have personalized content (menu looks different for every user depending on his permissions).

There are general integration strategies for this requirement.
Let me first outline the differences in cache-ability for 1 and 2:

For 1, the menu is totally cache-able.
For example, you could add a selector to the URL for user with and without permissions (menu.anonymous.html vs. menu.logged-in.html). With this approach, the application will make the decision which menu to integrate for a certain user. You would want to ensure that this mechanism is somewhat secured and can't be tampered with from the public. Please note: this can also be scaled to a certain amount of different groups (= variations of the menu) but I would keep the number as low as possible (probably a low 2-digit number as maximum).

For 2, you won't be able to cache it. You would need to cache a dedicated page for each user and that most probably will outweigh any gains achieved by caching in the first place.

Coming to the integration strategies:

Loading and integrating the menu client side (via JavaScript/Ajax)
This approach is commonly used when it comes to personalized content or integration of data from 3rd party systems (e. g. integrating a shopping cart, a "Welcome, John Smith" banner, or similar)
Integration on Apache HTTPD/Dispatcher level
For certain use cases, Server Side Includes (SSI) on web server level can be leveraged. This can be handled dynamically e. g. based on a users session, headers or other environment variables available to the web server. For permission related use cases it is usually necessary to somehow integrate Apache with the system managing the authorizations. I've seen setups handling authentication and authorization on Apache level through certain Apache modules and leveraging the resulting information in SSIs.
Sling Dynamic Includes
Probably the best fit for most use cases and commonly recommended is the approach of Sling Dynamic Includes. It combines SSI (see above) in a more integrated way with AEM/Sling.

Update:

Two more things to consider:

Depending on the level of security that is required, don't just look at the links but also put access control for the actual target pages in place.
Is the header section the only place where you have links to these target places?
Things may get quite complicated if there are other links to these protected pages spread across the website, e. g. content editors adding these links to regular pages.

Hope that helps!

Asutosh_Jena_ · Answer

Hi @kamal_kishor

You can create 2 different XF(Experience Fragment) one holding navigation content for logged in user and one holding the content for non-logged in user.

By default show the non logged in state content and logged in content can be shown only when you identify the user is logged in which again can be managed in multiple ways such as:

You can create a cookie when the user is logged in and when the user is not logged in or logs out, you need to remove the cookie. So based on cookie availability you can switch the content from JS. Here the complete content will be cached and the logic will be driven at the frontend.
If you don't want to go with JS approach, then you can go for sling dynamic include (SDI) and include a component which will invoke the Sling Model in backend and will provide you the dynamic path for the experience fragment with the relevant content. In this way, the whole page will still be cached at the dispatcher except the header section which is loaded using the SDI approach. The logged in or non-logged in state needs to be managed in Sling Model here.

Now coming to user validation on each request, You can set some unique value(let's say session id) in the cookie by encrypting it in AEM using the Crypto support and each time you make a call, you will need to invoke a service on backend which will read the cookie value, decrypt the cookie value and will check if it;s valid or not. If it's a valid session, it will allow you to proceed further, else you can handle the error based on your use case i.e., either you can redirect to 500 error or you can show some error message saying you have been logged out.

AEM Crypto Support: https://www.argildx.com/technology/crypto-support-aem/

Sling Dynamic Include: https://experienceleague.adobe.com/docs/experience-manager-learn/foundation/development/set-up-sling-dynamic-include.html?lang=en

https://www.argildx.com/technology/sling-dynamic-include-sdi/

Thanks!