ah - so the AuthStorage flips between Cookies and Sessions for the
auth data storage -- that makes more sense.
I still dont see how this creates a "valid" authenticationInfo object:
private AuthenticationInfo createAuthInfo(final String authData) {
final String userId = getUserId(authData);
if (userId == null) {
return null;
}
final AuthenticationInfo info = new AuthenticationInfo(
HttpServletRequest.FORM_AUTH, userId);
info.put(attrCookieAuthData, authData);
return info;
}
Is this enough to create an authorizable authinfo object?
info.put(attrCookieAuthData, authData);
attrCookieAuthData indicates the name of the cookie/request attribute,
and authdata looks like the contents of the cookie/session attr.
Is the decomposition and validation of the authData happening
someplace else (login module)?
The whole token in the JCR seems like it has its own pitfalls w
thinking about persistence/latency -- and even possible performance
implications. Using HMAC-SHA1/MD5 i can determine the validity of a
Cookie in memory (without having to hit the disk/io) -- and by pass
login module execution if I know the cookie is invalid.
On Tue, Apr 3, 2012 at 10:42 AM, David G. <[email protected]> wrote:
>
> Correct - a RESTful platform should not depend on the transient state of a
> server (Session).
>
> Its possible its storing it in the JCR, thought the Sling code appears to be
> storing it int he Session.
>
> See the last few methods in and trace back up the call
> stack: http://svn.apache.org/repos/asf/sling/trunk/bundles/auth/form/src/main/java/org/apache/sling/auth/form/impl/FormAuthenticationHandler.java
>
> It seems that the securetokennumber is used to help prevent cookie spoofing
> even after the cookie itself has expired (i think?)
>
> it seems like the the Password is getting stored somewhere unhashed (the
> session, certainly not the cookie) so the user can be authenticated w each
> request. I dont see the user of trusted-credentials anywhere, though there
> may be some other auth mechanism in play that im not aware of.
>
> Also, wouldnt persisting data to the JCR be asking for persistence lag? It
> seems very possible that the client (could be programmatic and hot human)
> could issue HTTP requests faster than the secure data could be persisted
> between all JCRs in the cluster (especially if the JCRs are distributed
> geographically). I've seen issues where redirects after user registration can
> result in errors because the user data hasnt been persisted to another JCR
> (in the same data center) on a simple redirect (used sticky sessions to solve
> this issue).
>
>
> On Tue, Apr 3, 2012 at 10:29 AM, Sarwar Bhuiyan <[email protected]>
> wrote:
>>
>> Are you talking about what happens when user requests are load balanced and
>> a request could potentially go to different servers?
>>
>> I'm not sure what the detail is for the form auth handler but could be the
>> secure token is temporary stored in the user's JCR node?
>>
>> Sarwar
>>
>> On Tue, Apr 3, 2012 at 3:04 PM, David G. <[email protected]> wrote:
>>
>> > Hi,
>> >
>> > So i've been poking around the src for Sling's FormAuth handler to
>> > understand how its built out and ran into something slightly alarming (I
>> > could just not be following the code through properly though).
>> >
>> > It seems that Sling Form Auth works like this:
>> >
>> > 1) User provides user/pass
>> > 2) User's user/pass are validated
>> > 3) User's autoinfo (password, secureTokenNum, etc.) are stored in the
>> > Session(??)
>> > 4) User is issued a cookie wi the userId and secureTokenNum
>> > 5) User makes a request w the cookie
>> > 6) Sling validates the cookie (looking up secureTokenNum in the Session)
>> > 7) User gets the authInfo (password) from the Session and sends it to the
>> > LoginModule
>> >
>> > Is my understanding of this correct?
>> >
>> > If so how does this solution scale across servers? Is there some
>> > persistence mechanism im missing? Or are users being logged in using
>> > something like trust credentials?
>> >
>> > Thanks
>> >
>
>
