Sling Servlet Best Approach

[MatthewDa19]

Hi everyone,
I have a few path- and resource-based servlets.

For path-based servlets, the URL starts like: http://localhost:4502/bin/test/v1/<identifier> Is exposing /bin to end users considered a problem? If yes, why so, since /bin/test/v1 is not a valid content path in AEM?

In my case, I want to mask /bin/test/v1/<identifier> with a proxy. This proxy will be called from the client side, and I plan to add Apache rewrite rules to map the proxy URL back to the actual servlet. Is this the best way?

For resource-based servlets, the URL starts like: http://localhost:4502/content/test/.../<page>.selector.extension I am masking these too with a proxy. Clients will call the proxy, and I’ll redirect it to the servlet API.

My main question: Is writing Apache rewrite rules the best solution here, or would it be better to use something like Sling resource mapping?

Thanks in advance!

[SantoshSai]

Hi @MatthewDa19,

Is there a specific reason you’re registering your servlet using path?
If you use a resourceType instead, you won’t need to expose /bin or mask it. You can leverage selectors and extensions directly on content paths.

Docs for reference: https://sling.apache.org/documentation/the-sling-engine/servlets.html

Are you constrained to path-based servlets for some reason?

[MatthewDa19]

@SantoshSai Thansk for your response!
I can switch some of them to resourceType-based servlets, but for others I still need path-based ones (integration APIs that aren’t tied to content). That’s why I’m worried about exposing /bin and considering masking it behind a proxy. Would exposing /bin directly actually be a problem?

[SantoshSai]

@MatthewDa19 

It's not inherently a security risk, but it’s not considered best practice either.

• With path-based servlets, you lose repository-level access control.

• With resourceType-based servlets, you can apply auth/authz policies on the resource.

That’s why Adobe generally recommends using resourceType where possible.

If you must stick to path-based:

• Keep them under /bin/ (not /apps or /libs)

• Control access via Dispatcher filters or custom filters

• Only add rewrites if you want to make URLs “prettier” for end users, but don’t rely on rewrites for security

[SantoshSai · Accepted solution]

In short:

• You can expose /bin paths, and technically it will work fine.

• It’s not best practice, because:

  • You lose repository-level access control.

  • It makes governance harder in multi-tenant or enterprise setups.

• Preferred approach -> use resourceType-based servlets for most cases.

• If path-based is required, secure it properly at the Dispatcher and AEM filter level.

• Use Apache rewrites only if you need nicer/proxy URLs, not as a replacement for proper servlet registration.

References:

• https://sling.apache.org/documentation/the-sling-engine/servlets.html
• https://sourcedcode.com/blog/aem/aem-sling-servlet-resource-type-for-post-get-code-example-code

[arunpatidar]

Hi @MatthewDa19 

You should register your servlet with resourceType.

if you calling the api at clienside then I would suggest to expose the path in metatag and use that.

Example

<!-- <meta name="basepath" content="currentPagePath.selector.extension"> -->
<meta name="basepath" content="/content/mysite/us/en.api.json">

And you can register your servlet with

@SlingServletResourceTypes(resourceTypes = "cq/Page", methods = HttpConstants.METHOD_GET, selectors = Constants.API_SERVLET_SELECTOR, extensions = Constants.EXTENSION_JSON)