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) ?
>
> 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 ?
> 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.
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/
