> > > Thank you very much for the explanation. Just another
> > > possible solution occurred to me:
> > >
> > > 1) to define "ask" functions like this in secured beans:
> > >
> > > public boolean canModify(MyBean obj) {
> > > return true;
> > > }
> > > public boolen canInsert() {
> > > return true;
> > > }
> > >
> > > 2) apply to those functions the required roles in the
> > > MethodSecurityInterceptor definition
> > >
> > > sample.contact.ContactManager.save=CONTACT_OWNED_BY_CURRENT_USER
> > >
> sample.contact.ContactManager.canModify=CONTACT_OWNED_BY_CURRENT_USER
> > >
> > > 3) then those functions can be safely called because in case
> > > of Granted access they will return true and will not perform
> > > any action and in case of denied access they will throw
> an exception:
> > >
> > > try {
> > > myService.canModify(myBean);
> > > // access granted code
> > > } catch (AccessDeniedException ex) {
> > > // access denied code
> > > }
> >
> > Hi Karel
> >
> > Yes, that would indeed work. There are so many ways of approaching
> Swing...
> >
> > For instance, I'm using JGoodies Swing Suite and its nice binding
> framework
> > (although you can implement bound bean properties pretty
> easily yourself).
> > GrantedAuthority[]s get placed in a bound bean property on
> the client side
> > after login. This fires a property change event, which all menu bar
> > builders, tool bar builders and views have registered to
> receive. Each
> view
> > then re-evaluates whether it will provide services to the user and
> > enables/disables itself as appropriate. Bound properties
> are also used for
> > the username and password. What does that buy us? Well, we can have
> > login/logout as a menu option without manually invoking a process to
> > enable/disable menus, toolbars and views. We can also have
> a "refresh
> > security" menu option or automated background process, to
> keep the user's
> > current GrantedAuthority[]s accurate as well respond
> appropriately if the
> > account becomes disabled. If our manager bean is coded to
> support it, we
> > could also make this background process detect if the
> application as a
> whole
> > has been disabled, or will be shutdown at a given future
> time, to automate
> > the shutdown or change the state of the Swing client.
> >
> > Best regards
> > Ben
> Ben,
>
> Could you provide some code samples ?
Unfortunately providing code samples of what we use is difficult because it
all subclasses JGoodies code. However, Keith Donald is doing a great job on
Spring RCP. Once RCP is a little further developed I'll be able to write a
few RCP-specific classes to integrate Acegi Security login, action
validation etc for those interested. This can be part of the RCP or Acegi
Security projects, so people can get a jump-start on developing secure rich
clients.
If anyone needs anything urgently, please let me know and I can find out
from Keith the status of the different components we'd need in RCP.
Best regards
Ben
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
