If we can do it in such a way that it is applicable for any environment, I'd love it. Because Realms abstract JSecurity away from the application's domain model, it might be tricky to do this in a clean manner.
For example, you could pass in an Account object to the realm to be created. But that might mean that the application's domain object would have to implement our Account interface - not something that is considered a best practice (embedding a framework's interfaces in your core domain model). Realms were created for this purpose - to prevent this tight coupling. But, I'm of course open to ideas - maybe what you describe is perfectly suitable for simplified environments, maybe where people have text-based or file-based realms and don't want to create user/role/permission objects from scratch. In any case, I definitely look forward to it. Could you please create a Jira issue at https://issues.apache.org/jira/browse/JSEC and attach a patch? Thanks! Les On Thu, Jul 17, 2008 at 11:56 PM, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > We're planning on using JSecurity in some REST applications. Most of > JSecurity should work for us out-of-the-box with the exception that we need > our basic realms (text and database) to be mutable at runtime, so we can > provide simple user management functions for standalone environments. > > I have been looking at the realm implementations and don't think it will be > difficult to add support for runtime mutability of simple > user->role->permission mappings. Is this something the project would be > interested in as a contribution? > > -dain >
