AEM 6.5 Sonar Cloud Scan- Do not use Sling servlet paths to register servlet | Community
Skip to main content
N
NitroHazeDev
Level 9
March 25, 2022
Solved

AEM 6.5 Sonar Cloud Scan- Do not use Sling servlet paths to register servlet

  • March 25, 2022
  • 2 replies
  • 5562 views

All,

 

Anyone knows how we can easily resolve the issue "Do not use Sling servlet paths to register servlet" without major changes.This was identified in the code scan.

Does using "sling.servlet.paths.strict" mode help?

I have like 24 servlets 

 

https://experienceleague.adobe.com/docs/experience-manager-cloud-manager/using/how-to-use/custom-code-quality-rules.html?lang=en#do-not-use-sling-servlet-paths-to-register-servlets 

 

Regards,

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by BrettBirschbach

In cases where a servlet is actually tied to a web component on your websites, you can change your servlet to be configured with `sling.servlet.resourceTypes=<resource type of your component>` and then change your front end calls to instead be a URL directly to the component.  When your servlet is tied to your component, this is generally advisable, because in a multi-site situation this ensures the path of the request includes the root path of the current site, which allows your service to ensure it's response is contextual to the site.

 

That said, if you truly have servlets that need to answer on static paths, I think what you can probably do is effectively achieve the same thing as above by adding some `nt:unstructured` nodes to your JCR that have a declared `sling:resourceType` that you can then reference in your servlets (same way as if they were real components).

 

As an example, say you have a servlet with path /api/myservice right now.  In your jcr add:
/content (default AEM folder for content)

-> /api (type: nt:unstructured)

->-> /myservice (type: nt:unstructured, sling:resourceType: "/servlets/abc")

 

And then in your Servlet, instead of configuring:

`sling.servlet.paths="/api/myservice"`

you have

`sling.servlet.resourceTypes="/servlets/abc"`

 

This then allows ACL's to be set on the `/content/api/myservice` node to govern access to your servlet, if desired.

 

NOTE that you'd need to call AEM with the full path `/content/api/mysevice.json` for example, which you can alter in your dispatcher configs (e.g. shorten to /api/myservice) for external use.

 

Maybe not everything you need, but LMK if this helps.

 

2 replies

BrettBirschbach
Adobe Champion
BrettBirschbachAdobe ChampionAccepted solution
Adobe Champion
March 25, 2022

In cases where a servlet is actually tied to a web component on your websites, you can change your servlet to be configured with `sling.servlet.resourceTypes=<resource type of your component>` and then change your front end calls to instead be a URL directly to the component.  When your servlet is tied to your component, this is generally advisable, because in a multi-site situation this ensures the path of the request includes the root path of the current site, which allows your service to ensure it's response is contextual to the site.

 

That said, if you truly have servlets that need to answer on static paths, I think what you can probably do is effectively achieve the same thing as above by adding some `nt:unstructured` nodes to your JCR that have a declared `sling:resourceType` that you can then reference in your servlets (same way as if they were real components).

 

As an example, say you have a servlet with path /api/myservice right now.  In your jcr add:
/content (default AEM folder for content)

-> /api (type: nt:unstructured)

->-> /myservice (type: nt:unstructured, sling:resourceType: "/servlets/abc")

 

And then in your Servlet, instead of configuring:

`sling.servlet.paths="/api/myservice"`

you have

`sling.servlet.resourceTypes="/servlets/abc"`

 

This then allows ACL's to be set on the `/content/api/myservice` node to govern access to your servlet, if desired.

 

NOTE that you'd need to call AEM with the full path `/content/api/mysevice.json` for example, which you can alter in your dispatcher configs (e.g. shorten to /api/myservice) for external use.

 

Maybe not everything you need, but LMK if this helps.

 

    N
    NitroHazeDevAuthor
    Level 9
    March 25, 2022

    Thanks Brett,  Kindly assist with below.
    1. Is creating a node under /content or elsewhere wise?
    2. Any permissions that need to be provided (ACLs)- Re read the comment that acls will need to be provided to the /content/api node for servlet to be accessed
    3. The dispatcher currently has allow to /api/myservice, what do you propose we add in there to allow? just /content/api/*? to the filters
    4. Does proceeding with "sling.servlet.paths.strict" help resolve the sonar issue you think?https://sling.apache.org/documentation/the-sling-engine/servlets.html#caveats-when-binding-servlets-by-path 

    5. Anything wrt method "POST"/"GET" to watch out for? I plan to use this with method POST as well

     

    Marked the answer right cause it helped me implement a clean solution..Thank you once again @brettbirschbach 

      BrettBirschbach
      Adobe Champion
      BrettBirschbachAdobe Champion
      Adobe Champion
      March 25, 2022

      1) I dont see any harm creating under /content.  You may be able to choose an arbitrary path like /bin or /api at the base level of the JCR, but if you do you'll need additional dispatcher rules to open up that path.  However, I dont know off the top of my head if AEM Cloud Service even allows you to add arbitrary paths to the root of the JCR.

       

      2) Probably no ACLs required, since your static paths currently would have no permissions, and there shouldn't be any default "write" permissions to worry about on your publish servers under /content.

       

      3) Yes, but you can address this by shortening the URL via your dispatcher.  Or, you can probably also have /api/myservice.json resolve to /content/api/myservice.json by adding an appropriate sling mapping (see /etc/map)

       

      4) That's probably what I would do.  Makes things simpler for custom dispatcher configs or sling mappings if everything is under the same root path.

       

      5) If you add a sling mapping to AEM (per the answer to #3 above) you might not need to do anything at all different than what you had before.  Otherwise you would need to update your allow to include the parent node structure (e.g. /content or /content/api) as you suggest.  I would recommend only allowing GET on any generic rules with a * in the path, and if you need to also allow POST I would recommend only allowing for fully specified (no *) URLs.

       

      6) I dont believe so, as this does not address the core warning regarding the inability for AEM to set ACLs on a servlet request path that doesnt correlate with a JCR path.  However, feel free to give it a shot.

        kautuk_sahni
        Community Manager
        kautuk_sahniCommunity Manager
        Community Manager
        May 30, 2022

        @nitrohazedev 

        [Webinar | AEM GEMs] Looking under the hood - Cloud Manager 2022 | Register: https://adobe.ly/3t4jfgp  & Ask Questions related to this Webinar: https://adobe.ly/3O0rdzd 

        Date &Time: Wednesday, June 15, 2022 - 8 am PDT OR 5 pm CET OR 8.30 pm IST
        Speakers: Remus Stratulat & Shankari Panchapakesan

        Share this within your Organisation and with your AEM peers!!

        Kautuk Sahni
          Terms & ConditionsAccessibility statement

          Loading footer...