回复: 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)

喂喂喂
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, 喂喂喂 <[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


Reply | Threaded
Open this post in threaded view
|

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

Brian Demers
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, 喂喂喂 <[hidden email]> 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, 喂喂喂 <[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