| From | Sent On | Attachments |
|---|---|---|
| Daniel Honig | Dec 31, 2008 5:44 am | |
| Peter Ledbrook | Dec 31, 2008 6:22 am | |
| Daniel Honig | Dec 31, 2008 6:32 am | |
| Daniel J. Lauk | Jan 12, 2009 7:28 am | |
| Peter Ledbrook | Jan 12, 2009 7:44 am | |
| Daniel J. Lauk | Jan 12, 2009 7:55 am | |
| Les Hazlewood | Jan 12, 2009 8:03 am | |
| Daniel Honig | Jan 12, 2009 8:10 am | |
| Peter Ledbrook | Jan 12, 2009 8:16 am | |
| Daniel J. Lauk | Jan 12, 2009 9:34 am | |
| Les Hazlewood | Jan 12, 2009 10:19 am | |
| Daniel Honig | Jan 12, 2009 10:32 am | |
| Les Hazlewood | Jan 12, 2009 10:42 am | |
| Peter Ledbrook | Jan 12, 2009 1:02 pm | |
| Daniel Honig | Jan 12, 2009 2:19 pm | |
| Robert McIntosh | Jan 12, 2009 2:23 pm | |
| Les Hazlewood | Jan 12, 2009 2:29 pm | |
| Robert McIntosh | Jan 12, 2009 2:35 pm | |
| Les Hazlewood | Jan 12, 2009 2:48 pm | |
| Les Hazlewood | Jan 12, 2009 2:49 pm | |
| Robert McIntosh | Jan 12, 2009 2:57 pm | |
| Peter Ledbrook | Jan 12, 2009 10:58 pm | |
| Craig | Jan 13, 2009 7:45 am | |
| Peter Ledbrook | Jan 13, 2009 7:48 am | |
| Daniel J. Lauk | Jan 13, 2009 8:07 am | |
| Peter Ledbrook | Jan 13, 2009 8:21 am | |
| Craig | Jan 13, 2009 8:22 am | |
| Daniel J. Lauk | Jan 13, 2009 8:26 am | |
| Daniel Honig | Jan 13, 2009 5:24 pm | |
| Daniel J. Lauk | Jan 14, 2009 4:18 am | |
| Daniel J. Lauk | Jan 14, 2009 9:38 am | |
| Peter Ledbrook | Jan 14, 2009 11:45 pm | |
| Daniel J. Lauk | Jan 14, 2009 11:56 pm | |
| Peter Ledbrook | Jan 15, 2009 6:07 am | |
| Les Hazlewood | Jan 15, 2009 6:13 am | |
| Daniel J. Lauk | Jan 15, 2009 6:13 am | |
| Daniel J. Lauk | Jan 15, 2009 6:17 am | |
| Peter Ledbrook | Jan 15, 2009 6:27 am | |
| Les Hazlewood | Jan 15, 2009 6:28 am | |
| Daniel J. Lauk | Jan 15, 2009 6:36 am | |
| tramuntanal | Jan 15, 2009 6:41 am | |
| Les Hazlewood | Jan 15, 2009 6:43 am | |
| tramuntanal | Jan 15, 2009 6:51 am | |
| Daniel J. Lauk | Jan 15, 2009 8:50 am | |
| tramuntanal | Jan 15, 2009 9:28 am | |
| Les Hazlewood | Jan 15, 2009 9:33 am | |
| Daniel J. Lauk | Jan 15, 2009 11:52 am | |
| Daniel J. Lauk | Jan 15, 2009 12:05 pm | |
| Peter Ledbrook | Jan 15, 2009 12:23 pm | |
| Daniel J. Lauk | Jan 15, 2009 12:40 pm | |
| tramuntanal | Jan 16, 2009 12:59 am |
| Subject: | Re: [grails-user] JSecurity- Logging in a user without knowing the users password | |
|---|---|---|
| From: | Les Hazlewood (lhaz...@apache.org) | |
| Date: | Jan 15, 2009 9:33:56 am | |
| List: | org.codehaus.grails.user | |
On Thu, Jan 15, 2009 at 11:51 AM, Daniel J. Lauk <dani...@gmail.com>wrote:
Peter, is that method in the builder obsolete by now? I noticed when reading the JSecurity API, that the Subject is capable of creating a Permission object from a String all by itself. It does that by utilizing PermissionResolver objects.
Just a clarification - the Realm implementation uses a PermissionResolver, not the Subject directly. The default communication flow is like this:
DelegatingSubject --> SecurityManager --> Authorizer --> one or more Realms
A Realm, when receiving a string for a permission check uses its internal PermissionResolver to change it to a Permission instance and then checks that. The default PermissionResolver on all JSecurity default Realm implementations is a WildcardPermissionResolver.
The default one
is the WildcardPermissionResolver yielding WildcardPermission objects of course. See also http://www.jsecurity.org/api/org/jsecurity/subject/Subject.html#isPermitted(java.lang.String)<http://www.jsecurity.org/api/org/jsecurity/subject/Subject.html#isPermitted%28java.lang.String%29>
I think the plugin should get out of JSecurity's way and call Subject.isPermitted(String) directly rather than creating a Permission object on its own (bypassing PermissionResolvers). Would you agree?
That would probably be better. The Grails plugin should passthrough whenever possible, IMO - this would make Peter's life maintaining things much easier ;)
If so, I'll provide a patch for that.
Great!





