--- In flexcoders@yahoogroups.com, "Steven Webster" <[EMAIL PROTECTED]> wrote:
> Todd,
>
> >
> > I added an abstract SecureCommand class which implements Responder.
> >
>
> I like it; neat implementation, and definitely agree with you
> putting this functionality into the SecureCommand base-class.
>
> > Any command which accesses secured remote objects must extend
> > SecureCommand.
>
> Nice.
>
> > The showLogonWindow() method of SecurityDelegate takes one
> > argument: the original Event. So while calling that method
> > from ShowLogonWindowCommand, I pass a reference to the
> > original Event object with it.
>
> Again, I like this ... this is exactly the same scheme we used
> to implement on the other side of the wire in the dark ages of
> JSP development ;) We'd intercept the request, handle
> authentication, and the dispatch the original request forward
> depending on authentication success.
>
> > At this point the LogonWindow has a reference to the
> > username, password and a reference to the original event.
> > from here, when the logon button is pressed, the
> > LogonWindowViewHelper broadcasts an EVENT_LOGON event which
> > triggers the LogonCommand to execute. The LogonCommand's
> > execute method accesses the setUsernamePassword() method of
> > the SecurityDelegate.
>
> If you look at the ModelLocator, have you thought about
> simply keeping a UserPrincipal object in the model (same as
> keeping a Principal in the HTTP_SESSION in the bad old days) ?
After posting my original thread, I did think about this. One of my
secure commands (named whoAmISecureCommand) asks the middleware who the
user is. the middleware returns a UserPrincipal Value Object object
(named MemberVO) based on the user's principal which then gets set in
the ModelLocator.
On second thought, storing the username and password in an incomplete
MemberVO object in the ModelLocator is not a bad idea. My
SecureServiceLocator class can request the credentials inside of
getService() instead of implementing it's own setUsernamePassword()
method.
What do you think?
>
> >
> > The setUsernamePassword() method of the SecurityDelegate sets
> > the username and password properties of my own extended
> > ServiceLocator:
> > SecureServiceLocator. I use SecureServiceLocator in my
> > application's mxml files just like the ServiceLocator. I all
> > my secure RemoteObjects in there.
> >
>
> So are you keeping passwords unencrypted on the client ?
For now, I am. I don't want the user to have to input their credintials for
every request made to a secure remote object. Do you have any suggestions?
>
> > My SecureServiceLocator overrides cairngorm's ServiceLocator's
> > getService() method. Inside SecureServiceLocator's
> > getService() method, I call super's getService() to obtain a
> > reference to the service. At this point, I call the
> > setUsernamePassword() method of the service with the username
> > and password of the SecureServiceLocator which was set inside
> > of the SecurityDelegate's setUsernamePassword() method.
>
> Nice.
>
> Seems like a good implementation to me....I'm thinking more
> about how you're handling password authentication, but I like
> the general architecture.
Thanks for your input.
--
Todd Boland
Charged Software
>
> Best,
>
> Steven
>
> --
> Steven Webster
> Technical Director
> iteration::two
>
> This e-mail and any associated attachments transmitted with it may contain
> confidential information and must not be copied, or disclosed, or used by
> anyone other than the intended recipient(s). If you are not the intended
> recipient(s) please destroy this e-mail, and any copies of it, immediately.
>
> Please also note that while software systems have been used to try to ensure
> that this e-mail has been swept for viruses, iteration::two do not accept
> responsibility for any damage or loss caused in respect of any viruses
> transmitted by the e-mail. Please ensure your own checks are carried out
> before any attachments are opened.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
