AEM 6.3 migration osgi bundle whitelist error-osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative

[Hemant_arora]

Are you facing such errors while migrating to AEM 6.3 :

osgi bundle whitelist error-osgi-service is NOT whitelisted to use SlingRepository.loginAdministrative

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.

Consequently the following methods are being deprecated

• ResourceResolverFactory.getAdministrativeResourceResolver
• ResourceProviderFactory.getAdministrativeResourceProvider
• SlingRepository.loginAdministrative

and alternatively we started using service authentication method getServiceResourceResolver to get the resourceResolver and then making a systme user and mapping service with user in felix congigurations.

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 dont want to add it coz you need to make code changes and build again and deploy. Hold on thats gonna take another 1 hour. Ridiculous ! and then youe question why they keep on changing methods to get resourceResolver.

LETS 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 following link :

https://sling.apache.org/documentation/the-sling-engine/service-authentication.html

Copied from 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 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" ] 

Property	Type	Default	Description
whitelist.name	String	[unnamed]	Purely informational property that allows easy identification of different fragments.
whitelist.bundles	String[]	[]	An array of bundle symbolic names that should be allowed to make use of the administrative login functionality.

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 fragment 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.

Property	Type	Default	Description
whitelist.bypass	Boolean	false	Allow all bundles to use administrative login. This is NOT recommended for production and warnings will be logged.
whitelist.bundles.regexp	String	""	A regular expression that whitelists all matching bundle symbolic names. This is NOT recommended for production and warnings will be logged.

[kautuk_sahni]

Nice article!!

~kautuk

[smacdonald2008]

Excellent community Article!

[smacdonald2008]

Just tested this and it works! 

[Knennigtri]

I found this issue out on my own and then stumbled on this article while trying to understand this whitelist. This is needed for Brackets to work with AEM 6.3 (from what I can tell). You need to add aem-sightly-ide-api to the whitelist. Unfortunately, this just makes another error saying that WCMUse DNE for AEM 6.3... So from what I can tell, this API needs to be updated to use WCMUsePojo in order for the Brackets sync to work. When I learn more, I'll post a seperate thread for this.

[karthikreddii]

Very helpful

[Dinu_Arya]

Is there any other way to fix this issue without white listing the bundle? In my code, I'm using the system user to get the resource resolver but still I'm getting the same issue. Any idea?