That is indeed what I was looking for.  It works in 6.3 also, even though the documentation seems to be for 6.4.  When you view the configuration through the CRX, the value will show the encrypted text.  Then AEM magically decrypts it before it is sent to the service or external component.  I guess ...

It turns out there is an issue with the dispatcher version we are using.  I don't know if it effects all platforms, but it is not working correctly on 4.2.0 on IIS, x64 non-ssl version.I tested the same exact dispatcher configuration (dispatcher.any) on the latest dispatcher (v4.2.3) and the filter ...

It appears this is available starting in 6.3.  From the 6.3 release notes: "Support for all OSGI configuration properties to be stored in a protected encrypted form instead of clear text."  How do you enable this or is it done automatically?What I am really looking for is the LDAP Identity Provider ...

It appears this indeed is available starting in 6.3.  From the 6.3 release notes: "Support for all OSGI configuration properties to be stored in a protected encrypted form instead of clear text."  How do you enable this or is it done automatically?What I am really looking for is the LDAP Identity Pr...

That didn't work.  We run AEM within an application server and it's not possible to run at the root.  (We even had ACS unseccuessufully attempt to change that).  All of our /filter rules are prefixed with /mysite and we haven't had any issues since we launched the site over two years ago.I added a f...

I should have mentioned that.  We are using 4.2.0 on IIS.  x64 non-ssl version.

I want to disable any URL with query strings but allow those that don't.  The "Note:" section of Configuring Dispatcher says the following should work: /0001 { /type "deny" /method "*" /url "/mysite/content/test/*" } /0002 { /type "allow" /method "GET" /url "/mysite/content/test/*" } /0003 { /type "...

We do deny everything first.  The first line of our dispatcher.any filter section is: /0001 { /type "deny" /glob "*" }Since there are several other sections of the security checklist devoted to the dispatcher, I thought this particular section ("Incorporate controls at the application level; Control...

Right.  I know from that perspective.  Our deployment has one package that I wrote, so I know our selectors.  But I can imagine an application, perhaps poorly architected, that has many code packages where a developer might introduce a selector that could cause problems.  It would be nice to query t...

Under the guidance of the security checklist (Security Checklist​:  "Incorporate controls at the application level; Control the selectors in your application"), how would I determine all possible extensions and selectors that are running in my instance?