OK, this is what I think Ronald and I were talking about. This is all from memory, so don't hold me to this, but: By default, when configuring multiple realms, if one of the realms throws a configuration error, it is logged at debug. This is fine for some cases, (for example if a realm throws an AuthC exception, but the next realm in the list is successful.
For new users/applications this is less ideal, as it can result in _hidden_ config errors, that unless you turn up the log level you miss them. This was changed not too long ago based on a pull request, and then reverted in the next release due to the log spam this caused for existing users. I think the current level is _more_ correct given that making existing users change is not a good idea, (and telling users to ignore WARN logs for a given logger is bad idea. That said, I think this is still an issue. Maybe we could make remote realm smarter, for example Log a WARN if an LDAP or DB connection timed out, and DEBUG, for other exceptions. (just throwing out ideas) On Wed, Dec 21, 2016 at 12:12 AM, 喂喂喂 <[email protected]> wrote: > I found out I can handle the exception thrown in the login process by > using slf4j and log4j. I didn't configure the log so I couldn't handle the > exception before, but the log level is hard-coded which I think may be not > good enough. Should users decide the log level(For example, we may set the > log level in the configuration file)? And is the way to handle the > exception too covert? > > > ------------------------------------------------------------ > ------------------------------------------------------------ > ------------------------------------------------------ > > Weekend ;) > > We defiantly should be logging the exception, at what level is probably a > (though related) different discussion. > > A test case is probably the first thing we need. Thanks for opening the > issue! > > > On Mon, Dec 19, 2016 at 12:04 AM, 喂喂喂 <[email protected]> wrote: > >> Hey, I have open a issue >> <https://issues.apache.org/jira/browse/SHIRO-606>, but there is no >> progress on the issue and no other JIRA user views the issue. >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------ >> ----------------- >> >> After looking at this, and the original comment, I _think_ I see what you >> are getting at. >> >> We should defiantly NOT be dropping/ignoring any exceptions. After my >> first read through, I was thinking this was a logging level issue. >> >> Liang, can you open a JIRA issue >> <http://issues.apache.org/jira/browse/SHIRO>, and include I high level >> overview of how we could reproduce this in a test? Of course providing a >> test would be ideal! >> >> >> >> >> >> On Thu, Dec 15, 2016 at 1:55 PM, Shawn McKinney <[email protected]> >> wrote: >> >>> >>> > On Dec 15, 2016, at 11:21 AM, Brian Demers <[email protected]> >>> wrote: >>> > >>> > There have been a couple issues on either side of this. >>> > >>> > These exceptions should be logged, as 'debug' (if i remember >>> correctly). Increasing the default logging can cause log spam in the cases >>> where multiple realms are enabled, and one is misbehaving (db is down, or >>> some network issue). >>> > >>> > The common (and valid complain) is similar to your as this does not >>> provide a good first experience, when setting up Shiro for the first time. >>> > >>> > Does anyone have any ideas on ways to both eliminate the log spam and >>> provide make it easier to troubleshoot for new installs? >>> > >>> >>> Hello, >>> >>> It has been my experience that a security handler should either log or >>> forward a downstream exception, but not both, to prevent the kind of log >>> spam you are referring to. Furthermore exceptions from downstream >>> resources, i.e. database / ldap servers, should probably be converted into >>> a common exception format, i.e. mysecurityhandlerexception, but the >>> original exception should always be included as a member of the new >>> exception class. >>> >>> That way information isn’t duplicated (in the logs) or lost, across the >>> entire lifecycle of the exception. >>> >>> HTH, >>> Shawn >> >> >> >
