I'm not sure where the disconnect is. JSecurity as a framework has at
its very core the notion of a dynamic security model - roles, users,
even individual instances, all able to be changed at runtime with no
hard-coding of any role names, etc. In fact, the framework was
founded due to this very requirement.
It is up to you however (or maybe a plugin) to do the actual
user/role/permission modifications and assignments. Your JSecurity
Realm just needs to know how to access those model objects when
executing a role/permission check. Are you asking that the JSecurity
Grails plugin provide this functionality (i.e. the web pages allowing
you to do the security modifications and permissions)?
And in regards to James' comments on requestMappings, the latest
version of JSecurity's requestMapping technique is the most succinct
and clean way of defining url mappings that I've seen, and is much
nicer than Acegi's mechanism. The JSecurity Grails plugin will have
this ability in its next release (it is in the current framework
release now, just not made its way yet into the plugin).
On Fri, May 16, 2008 at 9:05 AM, Jon.S <
bulkmailme@...> wrote:
>
> James,
>
> I plan to make the role dynamic as well. It is easier for me.
>
> Best Regards,
>
> Joni
>
> Joni,
>
> In JSecurity you can define all your filters on a role basis. If you have
> planned ahead there would be no need to re-code for each new user, jsut
> assign them to a certain role. That said having played with both I
> personally currently favour Acegi as I like the requestMapping style of
> securing things.
>
> James Hughes | Senior Software Engineer | Kainos | M: +353 (0)877 931 634 |
>
j.hughes@...
>
> P Please consider the environment and do not print this mail unless
> necessary
> --
> View this message in context:
http://www.nabble.com/jsecurity-VS-acegi-tp17272804p17274222.html> Sent from the grails - user mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>
http://xircles.codehaus.org/manage_email>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email