回复: A ponion about org.apache.shiro.authc.AbstractAuthenticator.authenticate(AuthenticationTokentoken)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

回复: A ponion about org.apache.shiro.authc.AbstractAuthenticator.authenticate(AuthenticationTokentoken)

喂喂喂
Hey, I have open a issue, 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, 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 <[hidden email]> wrote:

> On Dec 15, 2016, at 11:21 AM, Brian Demers <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: A ponion about org.apache.shiro.authc.AbstractAuthenticator.authenticate(AuthenticationTokentoken)

Brian Demers
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, 喂喂喂 <[hidden email]> wrote:
Hey, I have open a issue, 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, 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 <[hidden email]> wrote:

> On Dec 15, 2016, at 11:21 AM, Brian Demers <[hidden email]> 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