Different login pages for different routes about tapestry-security HOT 5 CLOSED

Oh that's certainly possible, even easy. If you only want the behavior when user clicks on the login link, I'd simply create a custom LoginLink component that generates different login urls based on the state/context. If you want the security to hand you a different login link based on the current page, you'd have to override LoginContextService (specifically, in 0.6.2 it's getLoginURL() ). The service is internal because the API is still somewhat unstable. One thing to note that security runs as part of HttpServletRequest pipeline so T5 Request, Responsed are not available yet. You can follow the implementation in LoginContextServiceImpl.createSavedRequestCookie() to create them if needed. Try implementing it and if you think the library can support the use case then open a more specific, for now I'm closing this as it seems there's no changes needed.

from tapestry-security.

If you want the security to hand you a different login link based on the current page, you'd have to override LoginContextService (specifically, in 0.6.2 it's getLoginURL() )

@kaosko I also thought it was easy, but actually, I'm not quite sure where to do this. Extending/implementing the page class with the LoginContextService interface is probably not the right way. Can you point me to the right direction?

Edit: I've been looking into http://tapestry.apache.org/ioc-cookbook-overriding-ioc-services.html, but find it hard to go further from there. Also looking into Service Advisors; http://tapestry.apache.org/service-advisors.html.

from tapestry-security.

Pages and services are different concepts so don't mix them. As explained on the ioc-services page you linked to, you'd do:

public class CustomLoginContextService extends LoginContextServiceImpl {
    @Override
    public String getLoginURL() {
        return "/some/custom/url";
    }
}

public static void bind(ServiceBinder binder)
{
  binder.bind(LoginContextService.class, CustomLoginContextServiceImpl.class).withId("CustomLoginContextService");
}

@Contribute(ServiceOverride.class)
public static void setupApplicationServiceOverrides(MappedConfiguration<Class,Object> configuration, @Local LoginContextService override)
{
  configuration.add(LoginContextService.class, override);
}

Finally, GitHub issues are not support forums. Join the mailing lists for more advice.

from tapestry-security.

I wasn't successful with this approach. I don't know how to make sure that the new CustomContextLoginService is only used by specific pages / page classes. Tried injecting the page with the service ID. As a side note, I had to implement all the other ContextLoginServiceImpl methods which I didn't want to override - did that by referencing the instance methods of the of the base service. This is just FYI what I tried, feel free to ignore this.

Thanks for looking into it, anyway. I thought that it might be of interest to the project and that's why I posted it here, but maybe it's too much of a niche use case to be taken seriously. Not trying to abuse the issues for support by any means. Will look into the mailing lists. Thanks again!

from tapestry-security.

No, a service is a singleton, you have to let go of the idea that different pages could use a different version of the same service. Instead, you should build the logic inside your one customized service based on the current page/context. Similarly to LoginContextServiceImpl.createSavedRequestCookie(), you could decode eventParameters, and based on getActivePageName() you'd return a different login URL.

Role based logic doesn't seem like it would work - the user would be unauthenticated at that point (unless you have a mechanism to identify the user first, for example with rememberMe cookie).

I don't think your request is too esoteric at all but I simply consider the library to already support your use case with simple enough customization.

from tapestry-security.