I wiped out lastLogin from the domain object, and nothing complained, so I'm assuming it was
half-implemented functionality anyway.
(It's my first week on this project. Still trying to figure out my way around.)
~~ Robert.
Burt Beckwith wrote:
> Yes, rememberMeServices resets the cookie and
> securityContextLogoutHandler invalidates the http session.
>
>
> Two places to look are resources.groovy/resources.xml for overridden
> beans and SecurityConfig.groovy.
>
>
> You asked earlier (
>
http://www.nabble.com/Disable-ACEGI-lastLogin--td24116114.html ) about
> the 'lastLogin' functionality that's most likely implemented as an
> onAuthenticationSuccessEvent callback registered in
> SecurityConfig.groovy - this is another opportunity for your custom code
> to change the user for each login.
>
>
> Burt
>
>
> On Thursday 02 July 2009 9:51:05 pm Robert Fischer wrote:
> > I'd already checked for bogus getters and missing transient labels.
> GORM stuff was the first place
> > I looked. :P
> >
> > Where can I track down custom code has been plugged into Spring
> Security? Where would you start
> > looking? I'm not sure how to make sense of some of the security
> config, and the team says that they
> > didn't write custom code. Are 'rememberMeServices',
> 'securityContextLogoutHandler' built-in
> > logoutHandlerNames?
> >
> > ~~ Robert.
> >
> > Burt Beckwith wrote:
> > > It's not Spring Security and it's not the plugin, it's your custom
> code.
> > >
> > >
> > > Spring Security uses a helper class to load the user domain class, and
> > > the plugin's implementation basically calls
> > > User.findByUsername(username) - it's a little more convoluted (using
> > > HQL) since there are config options, but it's a read-only
> operation. It
> > > loads the user, then loads authorities, extracts some field data and
> > > compares passwords. Simple.
> > >
> > >
> > > You most likely have a setter or a getter that's changing the value
> of a
> > > field. When Hibernate loads an instance it caches the original data
> and
> > > uses that for dirty detection - when flushing, if a value returned
> from
> > > a getter doesn't match the original value (either because the
> getter is
> > > customized or the setter was at instantiation) then it'll report a
> false
> > > dirty and push to the database.
> > >
> > >
> > > Burt
> > >
> > >
> > > On Thursday 02 July 2009 3:54:15 pm Robert Fischer wrote:
> > > > I don't know how or why, but ACEGI is mangling the user domain
> object
> > > state, and it's making
> > > > Hibernate think it's always dirty, although I can't see what
> > > property's changed. Any idea what
> > > > might be causing this behavior, or where I should go look to find it?
> > > >
> > > > ~~ Robert Fischer
>
>
--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog
http://EnfranchisedMind.com/blogCheck out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email