Announcement Announcement Module
No announcement yet.
always-use-default-target="false" and default-target-url do not work with spring-soci Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • always-use-default-target="false" and default-target-url do not work with spring-soci

    always-use-default-target and always-use-default-target="false" works fine if the user logins with username and password

    Both attributes seems to be ignored when using spring-social

    When the user logins using Facebook or Twitter:
    - If the user went to the login page because he/she clicked the "login" button, he/she is redirected to "/" after a successful login. I expected he/she to be redirected to default-target-url
    - If the user was redirected to the login page because he/she tried to access a protected url, he/she is also redirected to "/" after a successful login. I expected he/she to be redirected to original protected url he/she requested.

    I am using
    spring 3.1.3.RELEASE
    spring security 3.1.3.RELEASE
    spring social 1.0.2.RELEASE

    This is my spring-security.xml
    <beans:beans xmlns=""
    	<http use-expressions="true" access-denied-page="/ingresar/?acceso_denegado=true">
    	    <intercept-url pattern="/" access="permitAll" />
    	    <intercept-url pattern="/signin/**" access="permitAll" />
    	    <intercept-url pattern="/url1/**" access="permitAll" />
    	    <intercept-url pattern="/url2/**" access="hasAnyRole('ROLE_XXX')"/>
    	    <intercept-url pattern="/**" access="denyAll" />
    	    <form-login login-page="/url3/" default-target-url="/url4" always-use-default-target="false" 
    	                authentication-failure-url="/url5" login-processing-url="/url6"/>
    	    <logout logout-url="/logout"/>
    	<beans:bean id="myUserService" class="my.kalos.service.MyUserServiceImpl"/>
    	<beans:bean id="encoder" class=""/>
        <authentication-manager alias="authenticationManager">
        	<authentication-provider user-service-ref='myUserService'>
        		<password-encoder ref="encoder"/>
    This is my spring-social config class

    public class MyAppSocialConfig {
    	MyAppConnectionSignUp myAppConnectionSignUp;
    	private DataSource dataSource;
    	public ConnectionFactoryLocator connectionFactoryLocator() {
    		ConnectionFactoryRegistry registry = new ConnectionFactoryRegistry();
    		registry.addConnectionFactory(new FacebookConnectionFactory(myAppConf.getFbAppId(), myAppConf.getFbAppSecret()));
    		registry.addConnectionFactory(new TwitterConnectionFactory(myAppConf.getTtConsumerKey(), myAppConf.getTtConsumerSecret()));
    		return registry;
    	public UsersConnectionRepository usersConnectionRepository() {
    		JdbcUsersConnectionRepository repository = new JdbcUsersConnectionRepository(dataSource,
    				connectionFactoryLocator(), Encryptors.noOpText());
    		return repository;
    	@Scope(value="request", proxyMode=ScopedProxyMode.INTERFACES)
    	public ConnectionRepository connectionRepository() {
    		Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
    		MyUser user = (MyUser) authentication.getPrincipal();
    	  return usersConnectionRepository().createConnectionRepository(String.valueOf(user.getId()));
    	@Scope(value="request", proxyMode=ScopedProxyMode.INTERFACES)	
    	public Facebook facebook() {
    	    return connectionRepository().getPrimaryConnection(Facebook.class).getApi();
    	@Scope(value="request", proxyMode=ScopedProxyMode.INTERFACES)	
    	public Twitter twitter() {
    		return connectionRepository().getPrimaryConnection(Twitter.class).getApi();
    	public ProviderSignInController providerSignInController() {
    		ProviderSignInController controller = new MyAppProviderSignInController(...);
    		return controller;

  • #2
    I see that you're using ProviderSignInController. One of the strengths of PSIC is that it is flexible to work with any security mechanism you may choose, even if that's not Spring Security. But in being flexible, PSIC is not deeply involved in how Spring Security works. It's up to *you* to tell it how to work via the SignInAdapter interface.

    Of course, this means that you must write all of the Spring Security-specific details into that SignInAdapter implementation. I recognize that it can be cumbersome. That's why in Spring Social 1.1.0, we've created SocialAuthenticationFilter.

    SocialAuthenticationFilter does much the same thing as ProviderSignInController. But what makes SAF different is that it is very coupled to Spring Security. Therefore, although it's not as flexible as PSIC, SAF is more useful when working with Spring Security. SAF is just another authentication filter in the Spring Security filter chain.

    Currently Spring Social 1.1.0 is at milestone 2, although I hope to be able to cut a milestone 3 within a few weeks. I'd appreciate it if you could check it out and try SocialAuthenticationFilter (there's no documentation yet, but there is a sample usage of it at Let me know how it works for you.


    • #3
      Hi Habuma.

      Thanks for your answer. I finally got time to see at this issue again.

      I followed your suggestions and it worked!

      Now, I have another (related) issue.

      Let's say a user signs up / signs in with Facebook using SocialAuthenticationFilter. Then he/she wants to publish something he/she has done on Twitter. I am using ConnectController to let the use connect to a second social network. It works. But ConnectController has the same problem ProviderSignInController had, it redirects users to a fixed URL, not the URL he/she was going in the first place. Is there any way to prevent that? I mean something like a "SocialConnectFilter"...


      • #4
        Well, you can extend ConnectController and override connectionStatusRedirect() to do pretty much anything you want. You'll need to create some form of request cache to store the original request in and then "remember" that in your override of connectionStatusRedirect().

        That said, I really don't like advising that you subclass ConnectController. To me, that seems like a heavy suggestion. I think I should look into offering some form of strategy to achieve the things that require extending ConnectController.

        There is no filter-based approach, although I have thought about it before. I don't think it'd be all that difficult to pull off a ConnectController-clone in filter form. Will have to think on that some more.


        • #5
          FWIW, I created to track the idea of a filter-based ConnectController equivalent. Due to a tight schedule between now and when I want to release 1.1.0, it's doubtful that this will make it into the 1.1.0 release. But it could end up in a 1.2.0 release.


          • #6
            It looks there is a bug on SocialAuthenticationFilter. Eg with Facebook... if the user presses "cancel" on Facebook (ie don't authorize the app) SocialAuthenticationFilter keeps redirecting the user again and again to Facebook (after a few attemps FB shows a "is this app bothering you?" message).
            ProviderSignInController redirects the user to the original sign up/in page with an error message. I expected SAF to do the same.


            • #7
              Good catch. I've created to track that bug.