Configurable success URL for security.loginForm on per component render basis

[balapal]

It is possible to configure a default success URL via SecuritySymbols.SUCCESS_URL

I would like add a new optional parameter to security.loginForm to being able to redirect to different page than the one configured via SecuritySymbols.SUCCESS_URL.

The rationale behind that I would like to redirect to different pages depending where the user has come from.

How do you feel guys feel about this? Would you merge this feature to tapestry-security if I fork it?

[kaosko]

Yes, federated accounts sign-in components already support returnPageName @parameter (return page is Oauth specific term). While the LoginForm was meant mainly as an example rather than reusable component, we can add support for the more common use cases. Take a look at https://github.com/tynamo/tynamo-federatedaccounts/blob/master/tynamo-federatedaccounts-core/src/main/java/org/tynamo/security/federatedaccounts/base/AbstractOauthSignIn.java and go ahead and implement getSuccessPageUri() similar to getReturnPageUri() (with caret support!) and I'll merge that in.

[balapal]

Thanks, will do.

[balapal]

I have started to implement this feature based on AbstractOauthSignIn,
If I understand correctly the caret support comes handy if you embed the login form in a page where you would like to return after successful login. For this scenario the context of the page is considered when constructing return URL.

For other pages than the current one it is not possible to pass context or parameters.
For my use case I would need context support. I have log in button on a page what takes the user to the log in page and up on successful log in the user should be redirected to the page where it came from.
To solve this I introduced a @Parameter String successURL to security.loginForm (default value is SecuritySymbols.SUCCESS_URL).
My getSuccessPageUri() simply returns it, so it's the responsibility of the client code to build the custom success URL.

    @Parameter(defaultPrefix = BindingConstants.LITERAL, value = "prop:defaultSuccessURL")
    private String successURL;

    @Inject
    @Symbol(SecuritySymbols.SUCCESS_URL)
    @Property(write = false)
    private String defaultSuccessURL;

    private String getSuccessPageUri()
    {
        if ("^".equals(successURL))
        {
            return pageRenderLinkSource.createPageRenderLink(componentResources.getPage().getClass()).toAbsoluteURI();
        }

        if (StringUtils.hasText(getSuccessURL()))
        {
            return getSuccessURL();
        }
        else
        {
            // Empty returnpageName denotes a base url. Default for default return page may be set to a non empty value.
            // If default is empty and not locally overridden, return the baseurl
            return baseURLSource.getBaseURL(request.isSecure());
        }
    }

    public String getSuccessURL()
    {
        return StringUtils.hasText(successURL) ? successURL : defaultSuccessURL;
    }

I was trying to research how would this should be done in the tapestry way, but this is I could come up.
I can confirm that this works for my use case.

@kaosko is this the right direction to support link context and parameters?

[balapal]

The client code looks like this:

Login.tml:

<t:security.loginForm successURL="prop:successURL">
 </t:security.loginForm>

Login.java

    @ActivationRequestParameter("successURL")
    @Property
    private String successURL;

Page that is navigating to Login page with custom successURL.
.tml

    <a t:type="pagelink" t:page="user/Login" t:parameters="loginQueryParams" class="navbar-button">
        <button class="btn btn-primary">${message:login}</button>
    </a>

.java

  @Inject
    private Request request;

    public Map<String, Object> getLoginQueryParams()
    {
        final Map<String, Object> queryParams = new HashMap<>();
        queryParams.put("successURL", this.request.getPath()); //getPath() returns URL containing the page context
        return queryParams;
    }

[kaosko]

Shiro's savedRequest cookies is meant exactly for that use case. support for savedRequest is meant to address the use case but comment out because the functionality was pushed down to LoginContextService Impl. You use a query parameter instead - wouldn't it be easier to just override LoginContextService for your purposes? (Just asking, it's quite possible I'm missing something from the picture).

[kaosko]

Closing. @balapal, see comments in my commit to see what was kept and what changed and why.