Hi Peter, What do you mean exactly by modifying a realm? I would guess that you mean changing state/attributes on an existing Realm instance. Is this correct? Or are you talking about adding or removing realm instances on the SecurityManager at runtime?
The application SecurityManager instance shouldn't need to be swapped at runtime. Any changes to its configuration should be dynamically applied, IMO. But this might be a different discussion - I don't see how modifying an existing realm instance's state would have any effect on the security manager. Confused, Les On Thu, Sep 3, 2009 at 6:50 AM, Peter Ledbrook<[email protected]> wrote: > Hi, > > The Shiro plugin for Grails tries to support automatic reloading of > realms. So when a user modifies a realm while the application is > running, the change takes effect almost immediately without the user > having to restart the servlet container. A side-effect of this feature > is that the security manager bean is reloaded. In other words, you get > a new instance of the security manager. > > The problem I'm facing is that the subject never gets updated with the > new security manager, so the user's changes to his or her realm don't > take effect as they should. I was using a nasty hack via Groovy to > update the securityManager field on the subject directly, but it is a > hack. Are there any other ways of updating the subject? Maybe creating > a new delegating subject with the new security manager? If not, any > ideas for changes to Shiro that might aid this? > > Thanks, > > Peter >
