Cannot see TwitterSignInController in the git repository

[abhinavm]

I am not able to find the TwitterSignInController in the git repository even though the XML file signin.xml refers to it. This controller is present in the M2 downloaded.

Can anyone please let me know if the version in Git is not the latest one?

Warm regards,
Abhinav

[Keith Donald]

Hi,
We're working on M3 where TwitterSignInController is no longer required. It's been replaced in favor of a general-purpose ProviderSignInController. We're in in the process of updating the samples right now.

Keith

[abhinavm]

Hi Keith,

Thanks for pointing that out to me. I have one more question that is unrelated, but hope you can give me some direction.

I am leading an open source called socialauth that aims to provide a common API for the common functionality exposed by providers like facebook, twitter and several others. I wanted to integrate it with spring-social so that users can take advantage of additional providers that are not supported with spring-social. Also I do not want to rewrite all providers that we have developed. So we are trying to write a single provider class that will be a wrapper of our own providers. Single class because we just have one interface called AuthProvider that we implement for every provider.

The problem we are facing is regarding connection factories. Since our providers are already coded and do not expose any access token or secret, I wanted to develop a connection factory of our own. Is this possible?

Secondly, in the ConnectController it checks instanceof OAuth connection factory so its not possible to plugin our own connection factory into the controller. Will that code be changed in M3 ? Have studied the code of spring-social to quite an extent but am really hoping for any guidance. Thanks a lot in advance for some of your time.

Warm regards,
Abhinav

[Keith Donald]

Yes you can create your own ServiceProviderConnectionFactories and you could look to extend ConnectController to create ServiceProviderConnections using your custom factories. Let me know if ConnectController needs to be better written for extension (it probably does).

Keith

[abhinavm]

Hi Keith,

Thanks for your response. We have managed to integrate our framework with spring-social but for couple of inelegant bits.

1. We developed a SocialAuthConnectionFactory that implements ServiceProviderConnectionFactory. However, as you pointed out we had to place another else block in ConnectController. But to better write the ConnectController, the change actually needs to happen in ConnectionFactory hierarchy. It is possible to write an OAuthConnectionFactory, that is extended by both OAuth1ConnectionFactory and OAuth2ConnectionFactory in such a manner that ConnectController does not need to refer to instanceof.

2. Currently, the MapServiceProviderConnectionFactoryRegistry has two methods, one for FindByProviderId and another FindByServiceApi. The problem is that what we intend to implement is a common ServiceApi for all providers, so the serviceApiIndex does not work. We got around this problem by having our own registry which only implements FindByProviderId. We also had to modify the example classes like TwitterShowcaseController to use FindByProviderId instead of FindByServiceApi. This works, so I wanted to know if FindByServiceApi is really needed ?

I am happy to send you modified code for both the changes, would you like to take a look?

Warm regards,
Abhinav

[Keith Donald]

I'd definitely like to see your code mods... if those could be made available in a github fork of spring-social, that'd be excellent.

Anything we can explore to reduce the provider-specific logic in ConnectController I think is a good thing, so I'm very interested in that. As far as findByServiceApi, this is used to support type-safe lookup of Connections to specific Service API interfaces needed by application developers. I think this is a useful thing where it's simply not possible to rely on a common service API abstraction that applies across all providers. After all, there is quite a lot in each provider's API that is truly provider specific yet still needed for use by applications. In our model, the ServiceProviderConnection instance is designed to play the role of that common API with the help of the ServiceApiAdapter SPI. You can see that with the definition of common methods getUser(), test(), sync(), refresh(), and updateStatus(String message). I'm curious what else your own auth framework adds beyond these "common operations". My intention would be to have other truly common stuff added to ServiceProviderConnection, while provider-specific stuff can still be obtained via a call to getServiceApi(), then by invoking the strongly-typed provider-specific Java API binding interface.

Let me know when you have the code up on github in a forked spring-social repo and we'll take a look!

Keith

[abhinavm]

Thanks Keith,

I will clean up the code and will add it to a github fork. Your second comment was the guidance I had been looking for, i.e. common operations should go in the ServiceProviderConnection.

Right now, what we did was to create a SocialAuthApi that is obtained by calling getServiceApi on a SocialAuthProviderConnection. From your comment, I now understand that a better way would be to extend ServiceProviderConnection and incorporate the common functionality. The common functionality we have provided other than updating status and getUser is
a) ability to get contacts (with emails where possible)
b) a common api() method that can be used to send generic requests for example an arbitrary graph API request
c) ability to get Status

I will have a look at the possibility to do these common things in ServiceProviderConnection instead of having a SocialAuthApi. May take a few days to refactor, and will mail you as soon as we are done or face an issue in doing it that way.

Warm regards,
Abhinav