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