Betreff: How to design a page having different content fo...

[Kamal_Kishor]

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 , @markus_bulla_adobe , @Vijayalakshmi_S , @Pulkit_Jain_ , @Vaibhavi_J , @Ritesh_Mittal  

[markus_bulla_adobe · Accepted solution]

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!

[Kamal_Kishor]

thank you. I will try this and let you know if this works for us.

Apart from links in header, we have few pages where we want to show teaser content to anonymous users and then a link beneath the teaser to see the full content. Link will open a login pop-up, on successful login, the page will reload and show the entire content (page url remains same). We are going to migrate a site from php to AEM and we have to maintain the same url behavior.

thanks.

[Kamal_Kishor]

thank you. I will try this and let you know if this works for us.

[Asutosh_Jena_]

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:

1. 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.
2. 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...

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

Thanks!

[Kamal_Kishor]

thanks for quick response. I will try to evaluate and let you know if this works for us.

[arunpatidar]

Hi,

We had a similar requirement, to hide few links(protected links) for an anonymous user.

Our solution was -

1. Create a Sling rewriter (LinkTransformer) to find a protected link (based on cug:repPolicy node ) and add a class(link-protected--hide) and hide link by default

2. On front end side check if a user is logged in and has access to those link then remove the class link-protected--hide

The page is always same and cached.

In your case, you can specify those links from page properties and read them directly in the header (no need to create rewriter if changes are not global) and from end based on user type remove the hidden class or add the hidden classes

[markus_bulla_adobe]

That's a neat and straight-forward approach with quite low effort, @arunpatidar. Nice!
Be aware, however, that with this approach "protected" links will be exposed in the HTML source code. So you need to align this implication with the desired/required level of security.
Also, bots (e. g. search engines) or visually impaired visitors (using a screen reader or similar) won't recognize these links as "protected" and eagerly follow them.

That means, that the links (and the respective pages behind them) may be found by users, e. g. through

• Search engine results
• HTML source code inspection
• Screen readers and similar devices

While talking about security:
Don't just look at the links to you target pages, but also at these pages itself. Depending on your use case, there should be a mechanism in place to make sure that only logged-in users with according permissions are able to reach these pages.

[Kamal_Kishor]

thanks Arun. This could work for us. I will try and let you know if this worked for us.

[arunpatidar]

@markus_bulla_adobe  is right, based on your use case you need to handle accessibility and other security aspects. Though not a big effort but still required consideration.