Well, yes, it is up to interpretation, but that's ok - each Realm has
control over that already when it constructs the PrincipalCollection
that represents its own data.

But by our own convention, the 'primary' one is the first in the
collection (default behavior in all of our Realm implementations).
Our default Subject#getPrincipal() implementation assumes this - it
returns getPrincipals().iterator().next(); as the 'primary' one.  But
our assumption is not as solid as I would like for such a key concept
in the API.

The new method would be even more helpful multi-Realm scenarios: when
one or more realms are consulted during login, everything gets merged
into one final aggregate PrincipalCollection.  Again, we assume the
'primary' to be the first iterated element, which, in a multi-Realm
scenario, amounts to the first realm's first iterated element, which
is a heuristic.

That means if you want a universal identifier in your application -
Subject#getPrincipal() - you need to make sure that the Realm
responsible for that identifier is the first one in the Realm chain -
its not explicit at all and can be confusing when configuring your
Realms for the first time.

My thought is that adding the method

1. materializes something we already discuss frequently (which to me
means it probably should be represented in code somewhere) and
2. allows an end-user exact control over what the 'primary' principal
would be if they don't like our default heuristics.

My .02,

Les

On Tue, Sep 15, 2009 at 3:53 PM, Alan D. Cabrera <[email protected]> wrote:
>
> On Sep 15, 2009, at 12:22 PM, Les Hazlewood wrote:
>
>> I propose that we add a 'getPrimaryPrincipal()' method to the
>> PrincipalCollection interface.
>>
>> We regularly talk about the 'primary' principal, and it is referenced
>> in many applications, but you need to resort to less-than-ideal ways
>> of accessing it (see
>>
>> https://svn.apache.org/repos/asf/incubator/shiro/trunk/core/src/main/java/org/apache/shiro/realm/AuthorizingRealm.java
>> - 'getAvailablePrincipal' - at the bottom of the file).
>>
>> Most applications reference a single principal at runtime (e.g.
>> user/account ID), and I think it would clean up code.
>
> Isn't what is thought of the primary principal up to different
> interpretations?  Some realms may want it one way and others another.
>
>
> Regards,
> Alan
>
>

Reply via email to