Re: LoginManager.RestorePrincipal

Couple of questions?

-          Is this a 100% flash site, or an html/flash hybrid site?

-          Is the user initially logging the user in via Fluorine authentication or standard html forms authentication?

-          If you are logging in via Fluorine/flash, are you inheriting from the GenericLoginCommand class to do your authentication?

 

Fluorine should re-authenticate (call your DoAuthentication method) each time you setcredentials on your remoting calls. The Invoke method of the of the AuthenticationFilter class is what will re-authenticate your remoting call so long as you’ve setcredentials on your remoting calls. This essentially adds AMF headers to your request, this method checks for them and calls DoAuthentication if found and sets a principal (which is stored in cache by the way).

 

So if you make a remoting call to a “Login” method of your remoting class and setcredentials on the call for ‘User1’, then your Principal should be set to User1, then if you make another call to “Login” and setcredentials on the call for ‘User2’ then your Principal should now be User2.

 

The Invoke method uses the StorePrincipal and RestorePrincipal methods of the FluorineWebContext class. If you want to change the principal manually you could try to use the ClearPrincipal, StorePrincipal and RestorePrincipal methods of the FluorineContext.Current object.

 

Also, when using remoting authentication you shouldn’t always setcredentials on all of your calls since this will cause the DoAuthentication method to fire everytime. Though this will work, there is more performance overhead. Another option is to call setcredentials the first time you want to log in and then not setcredentials on subsequent calls. This will also work since the Principal is kept in cache, but if you server recycles, or the cache is turned over, then Fluorine has no way of re-authenticating. The preferred solution which seems to actually not be documented is:

-          Once you setcredentials and Fluorine authenticates your request, Fluorine will add an encrypted key to the AMF header response with the name of “data”.

-          You should use this value and on all subsequent requests to secured Fluorine methods, add a custom AMF header called ‘CredentialsId’ (ensure that you manually set the ‘Credentials’ header value to null).

-          When Fluorine recognizes this header it just persists the existing principal but doesn’t need to go through the whole re-authentication process.

-          This also adds a layer of security since username/passwords are not being sent over http on each request.

 

Hope this helps,

 

---

 

Shannon, thanks for you repply

 

Yes. After login to the app, the user cans change his profile by clicking a button.

 

But, how can I change credentials within Fluorine?

I tried setting HttpContext.Current.User...

But, after doing that, the security configuration (set on services-config.xml file) doesn´t apply, just mantains the first principal object (set by the first loggin)

 

I Checked FluorineContext.Current.User property is readonly

 

Thanks in advance

Andres Serral Coordinador de Desarrollo  andres.serral@...(54) 11.5239.2500 int. 514 Cabildo 2373 4º piso - Buenos Aires www.rs.com.ar

Por Favor considere el medio ambiente y no imprima este mail a no ser que sea absolutamente necesario. RS apoya el cuidado del medio ambiente.

 

From: Shannon Deminick [mailto:SD@...]
Sent: Tuesday, May 19, 2009 8:13 PM
To: andres.serral@...; Fluorine Mailing List
Subject: RE: [Fluorine] LoginManager.RestorePrincipal

Are you changing the profile within flash (i.e. by a user clicking a button?), if so ,you should just be able to setcredentials on a method call with the new credentials…

 

---

 

Andres Serral Coordinador de Desarrollo  andres.serral@...(54) 11.5239.2500 int. 514 Cabildo 2373 4º piso - Buenos Aires www.rs.com.ar

Por Favor considere el medio ambiente y no imprima este mail a no ser que sea absolutamente necesario. RS apoya el cuidado del medio ambiente.