« Return to Thread: ACEGI Mangling my user domain object state?

Re: ACEGI Mangling my user domain object state?

by Robert Fischer :: Rate this Message:

Reply to Author | View in Thread

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/blog

Check 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


 « Return to Thread: ACEGI Mangling my user domain object state?