| 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: | Robert McIntosh (pock...@gmail.com) | |
| Date: | Jan 12, 2009 2:57:28 pm | |
| List: | org.codehaus.grails.user | |
I understand the distinction. perhaps I am misusing the security filters then. my access stuff is done via;
before { accessControl { role("blah") } }
perhaps I took the quick start guide too literally? It didn't offer much documentation beyond the example. Perhaps I could do a a simple "return subject.principal != null" instead of a role check?
On Mon, Jan 12, 2009 at 2:49 PM, Les Hazlewood <lhaz...@apache.org> wrote:
Remember Me remembers your identity. It does _not_ remember your authentication state. See here for reasons why:
http://www.jsecurity.org/releases/0.9.0/docs/api/org/jsecurity/authc/AuthenticationToken.html
You can achieve 'remembered' UI features based on the check you perform. For example, if you want to show a person's UI state based on their identity, you can do the check this way:
if ( subject.principal != null ) { //the current user is either remembered from a previous session _or_ //they actually authenticated during their current session //so, show the UI state for user identified by subject.principal }
Contrast this with this:
if ( subject.authenticated ) { //They have actually logged in (principals & credentials) _during their current session_ //this code block will NOT execute if they are remembered, but haven't authenticated //during their current session. }
So, how you code the gui, based on these two checks is entirely up to you - one is more restrictive than the other (and absolutely should be), to allow the user access to information they must be authenticated for (e.g. seeing account data or credit card information, etc).
If one chooses to allow their end users the ability to see credit card information by only checking 'subject.principal != null', well, then, that's up to the implementor of the application, but I certainly wouldn't recommend it ;)
HTH,
Les
On Mon, Jan 12, 2009 at 5:35 PM, Robert McIntosh <pock...@gmail.com> wrote:
the assumption is that the purpose of "remember me" functionality is to not have to login on return trips. every site I've ever visited operated that way.
On Mon, Jan 12, 2009 at 2:30 PM, Les Hazlewood <lhaz...@apache.org> wrote:
What is useless? Remember Me works fine in my JSecurity-based applications...
Confused,
Les
On Mon, Jan 12, 2009 at 5:24 PM, Robert McIntosh <pock...@gmail.com> wrote:
I missed the original thread on this, but would this solve the "remember me" login as well? I can't for the life of me figure out why they would have that functionality that is basically useless...
On Mon, Jan 12, 2009 at 2:19 PM, Daniel Honig <dani...@gmail.com> wrote:
Ok guys, I summarized the complete approach as I read through, and I think it is a simpler and possibly more elegant approach than the originally suggested solution. (Or at least easier to understand). So I have compiled the steps I'm taking below and will report back before long with a note on my progress, here are my notes which as of now encompass three steps: Directions for the assuming a delegate subject with Jsecurity: 1.Create a class that assumes a delegate subject that is already set in the session. (The assumed identity would be set in a controller) class AssumingDelegatingSubject extends DelegatingSubject { public Object getPrincipal() { return this.session?.assumedIdentity ?: super.getPrincipal() } }
2. Create a subclass of DefaultSecurityManager that returns the custom subject. Per, the previous note, from Les Hazlewood. The SecurityManager implementation would need to be subclassed to return instances of your custom DelegatingSubject subclass. You do that by overridding this overloaded method:
http://www.jsecurity.org/api/org/jsecurity/mgt/DefaultSecurityManager.html#createSubject(org.jsecurity.subject.PrincipalCollection,%20org.jsecurity.session.Session,%20boolean,%20java.net.InetAddress) Your overridden method would return an instance of your custom DelegatingSubject subclass. "
3. Register the custom security manager in resources.groovy or resources.xml as jsecSecurityManager On Mon, Jan 12, 2009 at 4:03 PM, Peter Ledbrook <pet...@cacoethes.co.uk> wrote:
But there might be changes in the underlying SecurityManager *implementation* that would be backwards-incompatible. But this would only affect you if you manually override any of those implementation methods. I'm not sure if the Grails plugin uses with any of these methods or not or does custom implementation or wrapping of them.
The plugin uses the bog-standard JSecurity security manager for web apps - DefaultWebSecurityManager. It allows the user to easily configure the session mode and authentication strategy, but that's it.
Cheers,
Peter
--------------------------------------------------------------------- To unsubscribe from this list, please visit:
--------------------------------------------------------------------- To unsubscribe from this list, please visit:
--------------------------------------------------------------------- To unsubscribe from this list, please visit:
--------------------------------------------------------------------- To unsubscribe from this list, please visit:





