I'm not sure I follow, did you mean you want to set the log4j log level to WARN for the acegi package? If so then that won't solve the problem because the messages are being logged at WARN level right now, so we would need to go to ERROR level.
I would prefer not to discard all the messages Acegi is sending to INFO and WARN level logging, but I suppose that can't be helped if they insist on logging debug type messages at WARN level. -- Allen On Thu, 2005-12-01 at 14:06, Matt Raible wrote: > I think a reasonable solution would be to set the Acegi debug level to > be WARN. After all, we haven't been getting any authentication > messages from CMA before. > > Matt > > On 12/1/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > Actually, I don't even think these should be INFO level. We use INFO as > > the default log level and that means that on every attempted/successful > > login we would be getting these messages. That will be rediculous on a > > 2000 user system and I don't even want to think what it would look like for > > the jRoller guys. > > > > I think these messages need to be DEBUG level. > > > > -- Allen > > > > > > On Thu, 2005-12-01 at 12:35, Matt Raible wrote: > > > We could take out the LoggerListener bean in security.xml. I agree > > > that these should be set to INFO for successful authentications. I > > > can open an issue on this if you like. > > > > > > Matt > > > > > > On 12/1/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > > Matt, > > > > > > > > is there any way we can cut down on these kinds of messages without > > > > having to set the logger to ERROR level or higher? > > > > > > > > WARN 2005-12-01 11:08:32,047 LoggerListener:onApplicationEvent - > > > > Authentication event AuthenticationFailureBadCredentialsEvent: admin; > > > > details: [EMAIL PROTECTED]: RemoteIpAddress: 129.146.114.93; SessionId: > > > > FACEEDD1DA66AF85C817518776F193D5; exception: Bad credentials presented > > > > WARN 2005-12-01 11:08:50,331 LoggerListener:onApplicationEvent - > > > > Authentication event AuthenticationSuccessEvent: admin; details: [EMAIL > > > > PROTECTED]: RemoteIpAddress: 129.146.114.93; SessionId: > > > > FACEEDD1DA66AF85C817518776F193D5 > > > > WARN 2005-12-01 11:08:50,343 LoggerListener:onApplicationEvent - > > > > Authentication event InteractiveAuthenticationSuccessEvent: admin; > > > > details: [EMAIL PROTECTED]: RemoteIpAddress: 129.146.114.93; SessionId: > > > > FACEEDD1DA66AF85C817518776F193D5 > > > > > > > > why on earth would they have WARN level logging for simply indicating > > > > passed/failed authentications?? > > > > > > > > -- Allen > > > > > > > > > > > > On Mon, 2005-11-28 at 15:31, Allen Gilliland wrote: > > > > > On Mon, 2005-11-28 at 13:23, Matt Raible wrote: > > > > > > > > > > > > > > > > 1. Use the ports from roller.properties to configure SSL > > > > > > > > Switching. > > > > > > > > > > > > > > > > This should be configurable with a PortResolverImpl - here's an > > > > > > > > example: > > > > > > > > > > > > > > > > http://forum.springframework.org/showthread.php?t=19903 > > > > > > > > > > > > > > agreed. > > > > > > > > > > > > > > > > > > > > > > > 2. Add the channelProcessFilter to the "filterChainProxy" bean > > > > > > > > if SSL > > > > > > > > should be used to secure certain pages. > > > > > > > > > > > > > > can we do this programmatically? it would suck if users had to > > > > > > > modify the xml file in the webapp just to enable secure logins. > > > > > > > > > > > > We should be able to configure everything programmatically (after > > > > > > initial load). If you look at the new method I added to > > > > > > RollerContext, you'll see that many beans are manipulated after the > > > > > > fact. > > > > > > > > > > > > It should just be a matter of grabbing the existing property and > > > > > > manipulating it, then re-setting it. > > > > > > > > > > Ah, I get it now. Very cool. > > > > > > > > > > -- Allen > > > > > > > > > > > > > > > > > > > > > > > > > > >
