osgi bundle whitelist error-osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative
and alternatively, we started using the service authentication method getServiceResourceResolver to get the resourceResolver and then making a system user and mapping service with the user in Felix configurations.
like this <service-name>[:<subservice-name>]=<authorizable id of a JCR system user>]
IMAGINE YOU ARE A DEVELOPER AND YOU RESUME YOUR WORK AFTER LUNCH AND U HAVE BEEN ASKED TO RUN A GENERIC OSGI SERVICE ON AEM 6.3 AND YOU TRYING TO RUN THAT SERVICE BUT ITS GIVING THE ABOVE ERROR osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative
Relax, You might be aware of the fix(service authentication) but you still don't want to add it coz you need to make code changes and build again and deploy. Hold on that's gonna take another 1 hour. Ridiculous ! and then your question why they keep on changing methods to get resourceResolver.
Let's SAVE ONE HOUR IF YOU ARE USING THIS SERVICE OR BUNDLE ON LOCAL ENVIRONMENT.
How:
1) go to osgi configurations
2) search for keyword whitelist
3) click on add and give a name to config and bundle symbolic name
YOU ARE DONE!
Refer to the following link :
https://sling.apache.org/documentation/the-sling-engine/service-authentication.html
Copied from the above link:
Whitelisting bundles for administrative loginhttps://sling.apache.org/documentation/the-sling-engine/service-authentication.html#whitelisting-bun...
In order to be able to manage a few (hopefully legit) uses of the above-deprecated methods, a whitelisting mechanism was introduced with SLING-5153 (JCR Base 2.4.2).
The recommended way to whitelist a bundle for administrative login is via a whitelist fragment configuration. It can be created as an OSGi factory configuration with the factoryPID org.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment. E.g. a typical configuration file might be calledorg.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment-myapp.config and could look as follows:
All configured whitelist fragments are taken into account. This makes it easy to separate whitelists for different application layers and purposes.
For example, some Sling bundles need to be whitelisted, which could be done in a whitelist fragment named sling. In addition, myapp adds a whitelist fragment called myapp. For integration tests and additional whitelist fragments, myapp-integration-testing may be added.
The regular expression is most useful for running PaxExam based tests, where bundle symbolic names follow a set pattern but have randomly generated parts.
Example: to whitelist all bundles generated by PaxExam a configuration file named org.apache.sling.jcr.base.internal.LoginAdminWhitelist.config might look as follows:
Here is a quick hack but please ensure not to use it in production
I believe most of the AEM developers are aware that ResourceResolverFactory.getAdministrativeResourceResolver and SlingRepository.loginAdministrative methods have been defined to provide access to the resource tree and JCR Repository.
I believe most of the AEM developers are aware that ResourceResolverFactory.getAdministrativeResourceResolver and SlingRepository.loginAdministrative methods have been defined to provide access to the resource tree and JCR Repository.
Consequently, the following methods are being deprecated
ResourceResolverFactory.getAdministrativeResourceResolver
ResourceProviderFactory.getAdministrativeResourceProvider
SlingRepository.loginAdministrative
ResourceResolverFactory.getAdministrativeResourceResolver
ResourceProviderFactory.getAdministrativeResourceProvider
SlingRepository.loginAdministrative
and alternatively, we started using the service authentication method getServiceResourceResolver to get the resourceResolver and then making a system user and mapping service with the user in Felix configurations.
like this <service-name>[:<subservice-name>]=<authorizable id of a JCR system user>]
IMAGINE YOU ARE A DEVELOPER AND YOU RESUME YOUR WORK AFTER LUNCH AND U HAVE BEEN ASKED TO RUN A GENERIC OSGI SERVICE ON AEM 6.3 AND YOU TRYING TO RUN THAT SERVICE BUT ITS GIVING THE ABOVE ERROR osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative
Relax, You might be aware of the fix(service authentication) but you still don't want to add it coz you need to make code changes and build again and deploy. Hold on that's gonna take another 1 hour. Ridiculous ! and then your question why they keep on changing methods to get resourceResolver.
Let's SAVE ONE HOUR IF YOU ARE USING THIS SERVICE OR BUNDLE ON LOCAL ENVIRONMENT.
How:
1) go to osgi configurations
2) search for keyword whitelist
3) click on add and give a name to config and bundle symbolic name
YOU ARE DONE!
Refer to the following link :
https://sling.apache.org/documentation/the-sling-engine/service-authentication.html
Copied from the above link:
Whitelisting bundles for administrative loginhttps://sling.apache.org/documentation/the-sling-engine/service-authentication.html#whitelisting-bun...
In order to be able to manage a few (hopefully legit) uses of the above-deprecated methods, a whitelisting mechanism was introduced with SLING-5153 (JCR Base 2.4.2).
The recommended way to whitelist a bundle for administrative login is via a whitelist fragment configuration. It can be created as an OSGi factory configuration with the factoryPID org.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment. E.g. a typical configuration file might be calledorg.apache.sling.jcr.base.internal.LoginAdminWhitelist.fragment-myapp.config and could look as follows:
whitelist.name="myapp" whitelist.bundles=[ "com.myapp.core", "com.myapp.commons" ]
All configured whitelist fragments are taken into account. This makes it easy to separate whitelists for different application layers and purposes.
For example, some Sling bundles need to be whitelisted, which could be done in a whitelist fragment named sling. In addition, myapp adds a whitelist fragment called myapp. For integration tests and additional whitelist fragments, myapp-integration-testing may be added.
Furthermore, there is a global configuration with PID org.apache.sling.jcr.base.internal.LoginAdminWhitelist, which should only be used in exceptional cases. It has a switch to turn administrative login on globally (whitelist.bypass) and it allows supplying a regular expression to whitelist matching bundle symbolic names (whitelist.bundles.regexp).
The regular expression is most useful for running PaxExam based tests, where bundle symbolic names follow a set pattern but have randomly generated parts.
Example: to whitelist all bundles generated by PaxExam a configuration file named org.apache.sling.jcr.base.internal.LoginAdminWhitelist.config might look as follows:
whitelist.bypass=B"false" whitelist.bundles.regexp="^PAXEXAM.*$"
The configuration PID is org.apache.sling.jcr.base.internal.LoginAdminWhitelist. It supports the following configuration properties.
The configuration PID is org.apache.sling.jcr.base.internal.LoginAdminWhitelist. It supports the following configuration properties.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.