Redirect after successful login

[Les Hazlewood <lh...@apache.org>]

As posed by a user on the user list, he is using the
PassThruAuthenticationFilter and would like to redirect the user after
a successful login to the page the user was previously trying to
access before being asked to log in.

Currently, that logic exists in the AuthenticationFilter's issueSuccessRedirect:

https://svn.apache.org/repos/asf/incubator/shiro/trunk/web/src/main/java/org/apache/shiro/web/filter/authc/AuthenticationFilter.java

But this requires you to subclass the AuthenticationFilter to use this
logic - which people don't do with the PassThruAuthenticationFilter.

This method implementation does not require use of any class
attributes, so I propose moving that in to WebUtils (it already calls
2 other methods in WebUtils) so that it can be accessed by people
implementing their own controller logic in a single method call, and
so they don't have to copy-n-paste our code exposing our
implementation logic.

The existing issueSuccessRedirect method would stay to remain
backwards compatible, just immediately delegate to this new WebUtils
method call.

Any objections?

Les

Re: Redirect after successful login

[Kalle Korhonen <ka...@gmail.com>]

Thanks! I was looking at this and the inheritance hierarchy earlier,
and this is exactly the kind of change I was going to ask for, so
thanks for reading my mind :)

Kalle

On Tue, Jul 28, 2009 at 9:09 AM, Les Hazlewood<lh...@apache.org> wrote:
> I just committed this change - I don't think anyone will have any
> objections since all the other savedRequest related methods were
> already in WebUtils.  I can revert the change if anyone feels strongly
> otherwise.
>
> On Tue, Jul 28, 2009 at 11:13 AM, Les Hazlewood<lh...@apache.org> wrote:
>> As posed by a user on the user list, he is using the
>> PassThruAuthenticationFilter and would like to redirect the user after
>> a successful login to the page the user was previously trying to
>> access before being asked to log in.
>>
>> Currently, that logic exists in the AuthenticationFilter's issueSuccessRedirect:
>>
>> https://svn.apache.org/repos/asf/incubator/shiro/trunk/web/src/main/java/org/apache/shiro/web/filter/authc/AuthenticationFilter.java
>>
>> But this requires you to subclass the AuthenticationFilter to use this
>> logic - which people don't do with the PassThruAuthenticationFilter.
>>
>> This method implementation does not require use of any class
>> attributes, so I propose moving that in to WebUtils (it already calls
>> 2 other methods in WebUtils) so that it can be accessed by people
>> implementing their own controller logic in a single method call, and
>> so they don't have to copy-n-paste our code exposing our
>> implementation logic.
>>
>> The existing issueSuccessRedirect method would stay to remain
>> backwards compatible, just immediately delegate to this new WebUtils
>> method call.
>>
>> Any objections?
>>
>> Les
>>
>

Re: Redirect after successful login

[Les Hazlewood <lh...@apache.org>]

I just committed this change - I don't think anyone will have any
objections since all the other savedRequest related methods were
already in WebUtils.  I can revert the change if anyone feels strongly
otherwise.

On Tue, Jul 28, 2009 at 11:13 AM, Les Hazlewood<lh...@apache.org> wrote:
> As posed by a user on the user list, he is using the
> PassThruAuthenticationFilter and would like to redirect the user after
> a successful login to the page the user was previously trying to
> access before being asked to log in.
>
> Currently, that logic exists in the AuthenticationFilter's issueSuccessRedirect:
>
> https://svn.apache.org/repos/asf/incubator/shiro/trunk/web/src/main/java/org/apache/shiro/web/filter/authc/AuthenticationFilter.java
>
> But this requires you to subclass the AuthenticationFilter to use this
> logic - which people don't do with the PassThruAuthenticationFilter.
>
> This method implementation does not require use of any class
> attributes, so I propose moving that in to WebUtils (it already calls
> 2 other methods in WebUtils) so that it can be accessed by people
> implementing their own controller logic in a single method call, and
> so they don't have to copy-n-paste our code exposing our
> implementation logic.
>
> The existing issueSuccessRedirect method would stay to remain
> backwards compatible, just immediately delegate to this new WebUtils
> method call.
>
> Any objections?
>
> Les
>