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