You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Allen Gilliland <al...@sun.com> on 2007/07/26 18:16:20 UTC

Re: svn commit: r559865 - /roller/trunk/apps/weblogger/web/WEB-INF/security.xml

Hmmm, I don't know that there is no need for that cache.  That cache is 
used to prevent us from having to hit the db constantly when checking 
authentication/authorization.  Without it, every single request from 
users that are logged in requires extra queries against the db.

-- Allen


snoopdave@apache.org wrote:
> Author: snoopdave
> Date: Thu Jul 26 08:58:15 2007
> New Revision: 559865
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=559865
> Log:
> Fix for ROL-1492 "Change users profile and admin permissions feature does not work"
> 
> The problem is caused by the Acegi user-cache. The user's role is changed in the Roller DB, but Acegi is still hanging on to the old user object. So access to the Server Admin page is denied. 
> 
> There might be a way to flush the Acegi user cache, but I don't think there is much need for this cache and I'd rather not introduce any more Acegi dependencies. So I removed the cache from secrity.xml and that fixes the problem.
> 
> Modified:
>     roller/trunk/apps/weblogger/web/WEB-INF/security.xml
> 
> Modified: roller/trunk/apps/weblogger/web/WEB-INF/security.xml
> URL: http://svn.apache.org/viewvc/roller/trunk/apps/weblogger/web/WEB-INF/security.xml?view=diff&rev=559865&r1=559864&r2=559865
> ==============================================================================
> --- roller/trunk/apps/weblogger/web/WEB-INF/security.xml (original)
> +++ roller/trunk/apps/weblogger/web/WEB-INF/security.xml Thu Jul 26 08:58:15 2007
> @@ -125,12 +125,13 @@
>           
>      <bean id="daoAuthenticationProvider" class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
>           <property name="userDetailsService" ref="jdbcAuthenticationDao"/>
> -         <property name="userCache" ref="userCache"/>
> +         <!-- <property name="userCache" ref="userCache"/> -->
>      </bean>
>      
>      <!-- Read users from Roller API -->
>      <bean id="jdbcAuthenticationDao" class="org.apache.roller.weblogger.ui.core.security.RollerUserDetailsService"/>
>  
> +    <!--
>      <bean id="userCache" class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache">
>          <property name="cache">
>              <bean class="org.springframework.cache.ehcache.EhCacheFactoryBean">
> @@ -141,6 +142,7 @@
>              </bean>
>          </property>
>      </bean>
> +    -->
>     
>      <bean id="anonymousAuthenticationProvider" class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
>          <property name="key" value="anonymous"/>
> 
> 

Re: svn commit: r559865 - /roller/trunk/apps/weblogger/web/WEB-INF/security.xml

Posted by Dave <sn...@gmail.com>.
You have to flush the cache because the user is not the current user.
I've got code ready to commit that does the trick.

- Dave

On 7/26/07, Matt Raible <ma...@raibledesigns.com> wrote:
> You could also reset the authentication object:
>
> // reset the authentication object if current user
> 107             Authentication auth =
> SecurityContextHolder.getContext().getAuthentication();
> 108             if (auth != null && auth.getPrincipal() instanceof
> UserDetails) {
> 109                 User currentUser = (User) auth.getPrincipal();
> 110                 if (currentUser.getId().equals(user.getId())) {
> 111                     auth = new
> UsernamePasswordAuthenticationToken(user, user.getPassword(),
> user.getAuthorities());
> 112
> SecurityContextHolder.getContext().setAuthentication(auth);
> 113                 }
> 114             }
>
> From http://static.appfuse.org/appfuse-service/xref/org/appfuse/service/UserSecurityAdvice.html.
>
> Matt
>
> On 7/26/07, Allen Gilliland <al...@sun.com> wrote:
> >
> >
> > Dave wrote:
> > > On 7/26/07, Allen Gilliland <al...@sun.com> wrote:
> > >> Hmmm, I don't know that there is no need for that cache.  That cache is
> > >> used to prevent us from having to hit the db constantly when checking
> > >> authentication/authorization.  Without it, every single request from
> > >> users that are logged in requires extra queries against the db.
> > >
> > > Good point. I'll figure out how to flush that cache.
> >
> >
> > I took a quick look at it and I think you should be able to lookup the
> > "userCache" bean from spring and then call
> > userCache.removeUserFromCache(username).  The class used for caching is
> > this one ...
> >
> > http://www.acegisecurity.org/multiproject/acegi-security/apidocs/org/acegisecurity/providers/dao/cache/EhCacheBasedUserCache.html
> >
> > Generally speaking I don't like the idea of putting in more code that
> > directly tries to access spring beans, but I'm not sure there is any
> > other option here.
> >
> > -- Allen
> >
> >
> > >
> > > - Dave
> >
>
>
> --
> http://raibledesigns.com
>

Re: svn commit: r559865 - /roller/trunk/apps/weblogger/web/WEB-INF/security.xml

Posted by Matt Raible <ma...@raibledesigns.com>.
You could also reset the authentication object:

// reset the authentication object if current user
107             Authentication auth =
SecurityContextHolder.getContext().getAuthentication();
108             if (auth != null && auth.getPrincipal() instanceof
UserDetails) {
109                 User currentUser = (User) auth.getPrincipal();
110                 if (currentUser.getId().equals(user.getId())) {
111                     auth = new
UsernamePasswordAuthenticationToken(user, user.getPassword(),
user.getAuthorities());
112
SecurityContextHolder.getContext().setAuthentication(auth);
113                 }
114             }

>From http://static.appfuse.org/appfuse-service/xref/org/appfuse/service/UserSecurityAdvice.html.

Matt

On 7/26/07, Allen Gilliland <al...@sun.com> wrote:
>
>
> Dave wrote:
> > On 7/26/07, Allen Gilliland <al...@sun.com> wrote:
> >> Hmmm, I don't know that there is no need for that cache.  That cache is
> >> used to prevent us from having to hit the db constantly when checking
> >> authentication/authorization.  Without it, every single request from
> >> users that are logged in requires extra queries against the db.
> >
> > Good point. I'll figure out how to flush that cache.
>
>
> I took a quick look at it and I think you should be able to lookup the
> "userCache" bean from spring and then call
> userCache.removeUserFromCache(username).  The class used for caching is
> this one ...
>
> http://www.acegisecurity.org/multiproject/acegi-security/apidocs/org/acegisecurity/providers/dao/cache/EhCacheBasedUserCache.html
>
> Generally speaking I don't like the idea of putting in more code that
> directly tries to access spring beans, but I'm not sure there is any
> other option here.
>
> -- Allen
>
>
> >
> > - Dave
>


-- 
http://raibledesigns.com

Re: svn commit: r559865 - /roller/trunk/apps/weblogger/web/WEB-INF/security.xml

Posted by Allen Gilliland <al...@sun.com>.

Dave wrote:
> On 7/26/07, Allen Gilliland <al...@sun.com> wrote:
>> Hmmm, I don't know that there is no need for that cache.  That cache is
>> used to prevent us from having to hit the db constantly when checking
>> authentication/authorization.  Without it, every single request from
>> users that are logged in requires extra queries against the db.
> 
> Good point. I'll figure out how to flush that cache.


I took a quick look at it and I think you should be able to lookup the 
"userCache" bean from spring and then call 
userCache.removeUserFromCache(username).  The class used for caching is 
this one ...

http://www.acegisecurity.org/multiproject/acegi-security/apidocs/org/acegisecurity/providers/dao/cache/EhCacheBasedUserCache.html

Generally speaking I don't like the idea of putting in more code that 
directly tries to access spring beans, but I'm not sure there is any 
other option here.

-- Allen


> 
> - Dave

Re: svn commit: r559865 - /roller/trunk/apps/weblogger/web/WEB-INF/security.xml

Posted by Dave <sn...@gmail.com>.
On 7/26/07, Allen Gilliland <al...@sun.com> wrote:
> Hmmm, I don't know that there is no need for that cache.  That cache is
> used to prevent us from having to hit the db constantly when checking
> authentication/authorization.  Without it, every single request from
> users that are logged in requires extra queries against the db.

Good point. I'll figure out how to flush that cache.

- Dave