[
https://issues.apache.org/jira/browse/SHIRO-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Liang Weiwei updated SHIRO-606:
-------------------------------
Description:
In my opinion, AbstractAuthenticator.authenticate(AuthenticationToken
token) handles exception inappropriately. When the exception thrown in the try
block is not instance of Authentication, the method will wrap the exception to
a Authentication instance, and throw it all the way to
AuthenticatingFilter.executeLogin(ServletRequest request, ServletResponse
response), and just return a boolean.
The process mentioned above, make the exception ignored, which make it hard
for us to find out the mistake because the user can not take over the exception
handling job directly.
We can do some extension to handle the issue.I look into the source code
and find out two ways about handling the exception.First, write a class that
implements the AuthenticationListener, and inject it to the
ModularRealmAuthenticator instance, then the listener we write will handle the
exception in AbstractAuthenticator.notifyFailure(AuthenticationToken token,
AuthenticationException ae).Second,
FormAuthenticationFilter.setFailureAttribute(ServletRequest request,
AuthenticationException ae), this method seems insignificant and cant help,
because it only set a requset atrribute and the attribute value always is
"AuthenticationException", ignores everything about the original Exception.
Although there is a way to handle the exception on our own, I still dont
think the exception should be ignored in the Shiro log-in process.
In addtion, the way to handle the exception is a little tricky.In my
situation, I am using Spring with Shiro, and I have to write a Class that
extends the ModularRealmAuthenticator in order to inject the listener through
constructor-arg, because through value-inject a exception will be thrown.Of
course, without Spring, we could write a ModularRealmAuthenticator's subclass,
and assign a List<AuthenticationListener> to the instance's field.
It is easy to reproduce the issue, any exception thrown in the process
metnioned above will cause the problem.This is my first open issue and I am
sorry I dont know how to provide a test appropriately.
was:
In my opinion, AbstractAuthenticator.authenticate(AuthenticationToken
token) handles exception inappropriately. When the exception throw in the try
block is not instance of Authentication, the method will wrap the exception to
a Authentication instance, and throw it all the way to
AuthenticatingFilter.executeLogin(ServletRequest request, ServletResponse
response), and just return a boolean.
The process mentioned above, make the exception ignored, which make it hard
for us to find out the mistake because the user can not take over the exception
handling job directly.
We can do some extension to handle the issue.I look into the source code
and find out two ways about handling the exception.First, write a class that
implements the AuthenticationListener, and inject it to the
ModularRealmAuthenticator instance, then the listener we write will handle the
exception in AbstractAuthenticator.notifyFailure(AuthenticationToken token,
AuthenticationException ae).Second,
FormAuthenticationFilter.setFailureAttribute(ServletRequest request,
AuthenticationException ae), this method seems insignificant and cant help,
because it only set a requset atrribute and the attribute value always is
"AuthenticationException", ignores everything about the original Exception.
Although there is a way to handle the exception on our own, I still dont
think the exception should be ignored in the Shiro log-in process.
In addtion, the way to handle the exception is a little tricky.In my
situation, I am using Spring with Shiro, and I have to write a Class that
extends the ModularRealmAuthenticator in order to inject the listener through
constructor-arg, because through value-inject a exception will be thrown.Of
course, without Spring, we could write a ModularRealmAuthenticator's subclass,
and assign a List<AuthenticationListener> to the instance's field.
It is easy to reproduce the issue, any exception thrown in the process
metnioned above will cause the problem.This is my first open issue and I am
sorry I dont know how to provide a test appropriately.
> Exception thrown in the log-in process is being ignored.
> --------------------------------------------------------
>
> Key: SHIRO-606
> URL: https://issues.apache.org/jira/browse/SHIRO-606
> Project: Shiro
> Issue Type: Improvement
> Components: Authentication (log-in)
> Affects Versions: 1.3.2
> Environment: OS: Windows 10
> Java Version: 1.8.0_51
> Web Server:Tomcat 8
> IDE: Eclipse Mars for JEE
> Reporter: Liang Weiwei
> Labels: newbie, patch
> Fix For: 1.3.2
>
> Original Estimate: 101.5h
> Remaining Estimate: 101.5h
>
> In my opinion, AbstractAuthenticator.authenticate(AuthenticationToken
> token) handles exception inappropriately. When the exception thrown in the
> try block is not instance of Authentication, the method will wrap the
> exception to a Authentication instance, and throw it all the way to
> AuthenticatingFilter.executeLogin(ServletRequest request, ServletResponse
> response), and just return a boolean.
> The process mentioned above, make the exception ignored, which make it
> hard for us to find out the mistake because the user can not take over the
> exception handling job directly.
> We can do some extension to handle the issue.I look into the source code
> and find out two ways about handling the exception.First, write a class that
> implements the AuthenticationListener, and inject it to the
> ModularRealmAuthenticator instance, then the listener we write will handle
> the exception in AbstractAuthenticator.notifyFailure(AuthenticationToken
> token, AuthenticationException ae).Second,
> FormAuthenticationFilter.setFailureAttribute(ServletRequest request,
> AuthenticationException ae), this method seems insignificant and cant help,
> because it only set a requset atrribute and the attribute value always is
> "AuthenticationException", ignores everything about the original Exception.
> Although there is a way to handle the exception on our own, I still dont
> think the exception should be ignored in the Shiro log-in process.
> In addtion, the way to handle the exception is a little tricky.In my
> situation, I am using Spring with Shiro, and I have to write a Class that
> extends the ModularRealmAuthenticator in order to inject the listener through
> constructor-arg, because through value-inject a exception will be thrown.Of
> course, without Spring, we could write a ModularRealmAuthenticator's
> subclass, and assign a List<AuthenticationListener> to the instance's field.
> It is easy to reproduce the issue, any exception thrown in the process
> metnioned above will cause the problem.This is my first open issue and I am
> sorry I dont know how to provide a test appropriately.
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
