Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Best Practice - In Servlet should I only fetch the resource resolver from Request ?

Avatar

Community Advisor

Hi all,

 

I would appreciate your valuable input on this. As mentioned in https://stackoverflow.com/a/45232236, I believe that there is no harm in using a `resourceResolver` from the request in a servlet. However, I personally lean towards using the `ResourceResolver` from the service user rather than the request object as I believe it is more secure in the way we have control over the ACLs for service user.

 

With that being said, what is the best practice ? In which scenarios should we prefer the `ResourceResolver` from the service user over the `ResourceResolver` from the request? What are the best practices and what are the pros and cons?

 

Thank you.

Veena

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

The choice between using a ResourceResolver from the request or the service user depends on the specific requirements and security considerations of your application. Both approaches have their own pros and cons:

  1. Using ResourceResolver from the request:

    • Pros:
      • Simplicity: It is readily available in the request object, so you don't need to perform additional steps to acquire it.
      • Scoped to the current request: The resource resolver is tied to the current request lifecycle and is automatically closed when the request is processed.
    • Cons:
      • We need to assure that the user accessing the resource has just the right set of permissions. Both excessive/insufficient may generate unexpected results.
  2. Using ResourceResolver from the service user:

    • Pros:
      • Granular access control: Service users are typically dedicated accounts with specific permissions and ACLs defined separately. 
    • Cons:
      • Additional setup: Acquiring a resource resolver for a service user may require additional steps, such as configuring authentication and authorization mechanisms for the service user.
      • Manual management: Since the resource resolver is not tied to the request lifecycle, you need to explicitly manage its lifecycle, including closing it appropriately to avoid resource leaks.

Best practices:

  1. If your application doesn't have strict security requirements and the ACLs associated with the request's resource resolver are sufficient, using the resource resolver from the request can be a simple and effective approach.
  2. If your application requires fine-grained control over ACLs and stronger security measures, using a service user's resource resolver is recommended. This approach provides more control over access rights and helps mitigate potential security risks.
  3. When using a service user's resource resolver, ensure proper management of its lifecycle by closing it when no longer needed.

 


Aanchal Sikka

View solution in original post

6 Replies

Avatar

Community Advisor

Hi @VeenaVikraman 

It depends, if the servlet requires a resource resolver with more rights than the end user rights, then the resource resolver must be used from the service. But in most cases user has only read access to content area, so if servlet requires only read access then use resource resolver from request.

Using resource resolver from request will automatically close resource resolver, you don't have to do it explicitly unlike service-based resource resolver.

 



Arun Patidar

Avatar

Correct answer by
Community Advisor

The choice between using a ResourceResolver from the request or the service user depends on the specific requirements and security considerations of your application. Both approaches have their own pros and cons:

  1. Using ResourceResolver from the request:

    • Pros:
      • Simplicity: It is readily available in the request object, so you don't need to perform additional steps to acquire it.
      • Scoped to the current request: The resource resolver is tied to the current request lifecycle and is automatically closed when the request is processed.
    • Cons:
      • We need to assure that the user accessing the resource has just the right set of permissions. Both excessive/insufficient may generate unexpected results.
  2. Using ResourceResolver from the service user:

    • Pros:
      • Granular access control: Service users are typically dedicated accounts with specific permissions and ACLs defined separately. 
    • Cons:
      • Additional setup: Acquiring a resource resolver for a service user may require additional steps, such as configuring authentication and authorization mechanisms for the service user.
      • Manual management: Since the resource resolver is not tied to the request lifecycle, you need to explicitly manage its lifecycle, including closing it appropriately to avoid resource leaks.

Best practices:

  1. If your application doesn't have strict security requirements and the ACLs associated with the request's resource resolver are sufficient, using the resource resolver from the request can be a simple and effective approach.
  2. If your application requires fine-grained control over ACLs and stronger security measures, using a service user's resource resolver is recommended. This approach provides more control over access rights and helps mitigate potential security risks.
  3. When using a service user's resource resolver, ensure proper management of its lifecycle by closing it when no longer needed.

 


Aanchal Sikka

Avatar

Level 1

Thankyou so much for detailed Explanation ,now i 'm getting clarity