ACEGI Mangling my user domain object state?

[Robert Fischer]

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, 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

[Burt Beckwith]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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]

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

[Burt Beckwith]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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]

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