Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.37 as permitted sender)
Message-ID: <4D64BE01.5030605@adobe.com>
Date: Wed, 23 Feb 2011 08:57:53 +0100
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Subject: Re: Enhancement to the TokenBasedAuthentication
References: <1298282854.4515.200.camel@meschbix>	 <4D638710.2040800@adobe.com>
 <1298377133.4515.772.camel@meschbix>
In-Reply-To: <1298377133.4515.772.camel@meschbix>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

hi felix

> It would be nice if it would be possible to update the optional
> properties by supplying new/changed ones in subsequent logins using
> TokenCredentials.

that should be feasible... although i am a bit concerned about
the updating as additional write operations upon login should from
my point of view be as limited as possible.... anyway... will give
it a try and write some information output into the log that
allows us to track those updates for reconsideration later on.

regards
angela
> For example:
>
>     TokenCredentials t = new TokenCredentials(token);
>     t.setAttribute(attr2, attr2Value);
>     Session s = repository.login(t);
>     assert(attr2Value.equals(s.getAttribute(attr2)));
>     s.logout();
>
>     TokenCredentials t2 = new TokenCredentials(token);
>     Session s2 = repository.login(t2);
>     assert(attr2Value.equals(s2.getAttribute(attr2)));
>     s2.logout();
>
>
> Regards
> Felix
>
> Am Dienstag, den 22.02.2011, 10:51 +0100 schrieb Angela Schreiber:
>> hi felix
>>
>>> On creation of the token all SimpleCredentials attributes are copied to
>>> the token node. These attributes must be matched on subsequent requests
>>> with attributes from the TokenCredentials object supplied.
>>
>> not quite... all attributes are stored in the node but only those
>> marked as required attributes (having a leading '.token' will be
>> used for validation upon a subsequent login.
>>
>>>     * Attributes are either optional or mandatory. Optional attributes
>>>       present in the SimpleCredentials object are just stored in the
>>>       token node but are not matched on subsequent requests. Mandatory
>>>       attributes must be existing as secondary validation mechanisms
>>>       in subsequent requests.
>>
>> see above
>>
>>>     * When creating the Session from the SimpleCredentials (on first
>>>       access creating the token) only the optional attributes (plus the
>>>       token value of course) are copied to the Session attributes. The
>>>       mandatory attributes are not copied.
>>
>> makes sense... i will add that.
>>
>>>     * When creating the Session from the TokenCredentials (on subsequent
>>>       access validating the supplied token and mandatory attributes) the
>>>       optional attributes stored in the token node are copied to the
>>>       Session attributes while (again) the mandatory attributes are not
>>>       copied.
>>
>> same here.
>>
>>> This allows for preventing to leak mandatory attributes into the Session
>>> but also allows for using the token node as a temporary store for
>>> informational attributes.
>>
>> thanks for the review!
>> angela
>>
>
>