Use LoginModuleProxy (was: Make "Whiteboard" accessible through ContentRepository)

[Tobias Bocanegra <tr...@adobe.com>]

Hi,

On Thu, Feb 13, 2014 at 8:55 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
> On Thu, Feb 13, 2014 at 4:11 AM, Chetan Mehrotra
> <ch...@gmail.com> wrote:
>> Note here I preferred using the callback to get LM access the outer
>> layer services instead of using a custom config.
>>
>> The custom config mode works fine in standalone case where the
>> application is the sole user of JAAS system. Hence it works fine for
>> Karaf/OSGi env But that might not work properly in App server env
>> where app server itself uses jaas. So to avoid interfering in embedded
>> mode callback should be preferred.
>
> The problem with using a CallbackHandler for such things is that it
> forces the client code (that controls the CallbackHandler) to
> understand about the LoginModule implementation. Thus you can't use
> such a LoginModule with a client that relies only on the standard JAAS
> API.
well yes. but I think the LMs are never generic. They need to
understand the host application they are running in; especially with
more complex setup of different LMs. In reality, I don't think that a
LM that doesn't extend from Oak's AbstractLoginModule really works
great.

> As mentioned in a previous message, it's better to use the options map
> that comes from the runtime environment and can thus be controlled
> without touching the client code.
I think both are needed. As I wrote above, I think tightly Oak coupled
login modules even benefit from a fixed set of callback handlers. i.e.
it is more robust to write:

RepositoryCallback rcb = new RepositoryCallback();
callbackHandler.handle(new Callback[]{rcb});
securityProvider = rcb.getSecurityProvider();

than:

securityProvider = options.get(SecurityProvider.class.getName());

It is more transparent to the developer what backend objects are
retrievable, IMO.