Announcement Announcement Module
Collapse
No announcement yet.
spring-social-security: how to inject custom SimpleUrlAuthenticationSuccessHandler? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • spring-social-security: how to inject custom SimpleUrlAuthenticationSuccessHandler?

    After a successfull login on facebook with spring-social & spring-security (based on spring-social-security) the SimpleUrlAuthenticationSuccessHandler is called.
    Can someone explaine me how i can inject here my custom SimpleUrlAuthenticationSuccessHandler?

    (It would be the cleanest possibility to do some custom redirects after a successfule login.)

  • #2
    Because it's everithing autowired in this example, you'll need to config the authenticationfilter manually to reach this. Here an XML based example:

    <security:http
    ...
    <security:custom-filter after="FORM_LOGIN_FILTER" ref="mySocialSecurityAuthenticationFilter" />
    </security:http>

    <bean id="mySocialSecurityAuthenticationFilter" class="org.socialsignin.springframework.social.sec urity.signin.SpringSocialSecurityAuthenticationFil ter">
    <property name="authenticationSuccessHandler" ref="myUrlAuthenticationSuccessHandler" />
    </bean>

    Now you can do what ever you want in your custom AuthenticationSuccessHandler. E.g. redirect to the page where you're originally coming from...

    Comment


    • #3
      Hi

      Thanks for posting the solution to this - the ability for the authentication success url to be configured was something I'd meant to implement in earlier versions of spring-social-security but must had missed.

      I've made a couple of changes to the latest snapshot of spring-social-security recently - one of which is a fix for the issue you describe. If an environment property is set ( socialsignin.defaultAuthenticationSuccessUrl ) with the required authentication success url, the default springSocialSecurityAuthenticationFilter will now pick this up, and set this as the default for it's success handler.

      Other changes in the latest build include a provider-aware AccessDeniedHandler - now meaning that urls can be protected with provider-specific role combinations such as "hasRole('ROLE_USER_TWITTER') and hasRole('ROLE_USER_FACEBOOK')" - users without this authorisation will then be prompted to connect with the relevant provider(s) though the use of this handler.

      Cheers,

      Michael Lavelle

      Comment

      Working...
      X