400 Bad Request

[habuma]

Michael's right. If all you're doing is calling super.oauth1Callback() in the overriding method, then there's really no reason to override that method at all. (But if you do, be sure to annotate the providerId parameter with @PathVariable).

While we're on the topic, I've been wondering for a *long* time about overriding the connectView() method versus having a connectView property that can be configured in Spring. Certainly, overriding connectView() gives more flexibility in the sense that you could construct the returned value intelligently using whatever facilities Java offers...but I also think that the most common case would be a view that is expressed as a simple String (and thus, can be easily configured via Spring injection without creating a subclass of ConnectController). Curious what your thoughts are?

[Generic1]

Thanks a lot for guys for the help. I have added @PathVariable and overwritten connectedView:

@Override
protected String connectedView(String providerId) {
return "redirect:/home.htm";
}

Now it works great.

>> Curious what your thoughts are?
Actually my Spring experiences are a bit outdated. The last 6 years I have used OSGi and there override Methodes is common.
But thanks for the hint. I think I will configure it via Spring injection.

Thanks once again and all the best.
Generic

[Generic1]

I would have one last question.
For JdbcUsersConnectionRepository I need a dataSource (in my real web application it is a mysql connection) and in my MySQL Database I need a table like the SQL at the bottom. And in this table the user logged in over e.g. twitter where stored. Am I right or did I have something misunderstood?
Thanks once again.

By the way, if you are interested why I need all this things. We will implement Spring Social at this web application: http://www.atleticus.net

create table UserConnection (userId varchar(255) not null,
	providerId varchar(255) not null,
	providerUserId varchar(255),
	rank int not null,
	displayName varchar(255),
	profileUrl varchar(512),
	imageUrl varchar(512),
	accessToken varchar(255) not null,					
	secret varchar(255),
	refreshToken varchar(255),
	expireTime bigint,
	primary key (userId, providerId, providerUserId));
create unique index UserConnectionRank on UserConnection(userId, providerId, rank);

[michaellavelle]

With regards to Craig's question about overriding connectView() vs. having an injectable property, my personal opinion is that I like to keep the consistency and default behaviour of the current implementation, but I'd like to be able to customise this behaviour without subclassing. Ideally I'd like to be able to augment behaviour of an existing Spring Social webapp, allowing configurations to be changed through properties/composition rather than inheritance.

Considering my own use-case using spring-social-security :

I'd like to have a shared view which has connection options to available providers dynamically generated - a single jsp for example which accepts a "providerId" attribute and displays the relevant connect with provider buttons, or displays all provider connect options if this parameter is not present. Using the existing implementation of ConnectController, I've needed to create logical views for each provider (tiles definitions) - each referencing the same underlying jsp and passing in a "providerId" attribute to the jsp.

In this use-case, I'm registering new providers using component-scanning - having to create provider-specific views for essentially shared behaviour isn't as clean a solution as I'd like, and limits an application's ability to add new providers dynamically.

If ConnectController were able to be configured with its connectView through a property, this would remove the need to create these provider-specific views, *if* the relevant providerId were passed into the view as a model attribute for example.

I was wondering whether a hybrid approach may be possible? - to encapsulate the existing view name creation logic into a strategy class which can be injected into the ConnectController. This strategy could be set to the current strategy by default, but applications could inject their own alternatives - in my case a strategy to building up a single view with a model attribute set for the providerId.

This would allow new providers to be added (in my case through component-scanning) without the application needing to make provider-specific amendments.

(As an aside, if ConnectController were to go in this direction, I feel that the connectionStatusRedirect method would also need to be customisable in the same was as connectView).

Just my 2 cents worth - I think there are pros and cons to each approach and can see why it's a tricky issue to determine to the best approach.

[habuma]

Generic1: Yes, you'll need to create a table somewhat like what you described or as is described in JdbcUsersConnectionRepository.sql. Note, however, that JdbcUsersConnectionRepository.sql serves only as a guideline for how such a table should be created and may not work with all databases--you may need to tweak the schema to accomodate the quirks of whatever DB you're using.

I think you have a good understanding of what that table is used for, but to clarify the terminology: When you say "user logged in over e.g. twitter", it's actually an authorization process, not an authentication process--that is, the user is authorizing your application to access their data and post updates on Twitter. At the end of that authorization process (OAuth 1.0a in the case of Twitter), your application receives an access token and secret. On Twitter's end, they're already associating your application, the user, and the token/secret in whatever DB they use. Within a Spring Social-enabled application, the user connection repository (and the underlying table) is what keeps track of that relationship between your user, your application, and Twitter. We call that relationship a "connection".

To be clear again, ConnectController's job is to orchestrate the connection process, which is an authorization process. That said, the authorization process can be used as a form of authentication as well. ProviderSignInController is a Spring Social controller that can be used to orchestrate the connection process in such a way that the user ends up authenticated into your application.

[habuma]

Michael: Thanks for your insightful answer to my question regarding configuration vs. subclassing. Although I have different reasons for configuration of things like connectView (and other properties on ConnectController), they're consistent in spirit to your reasons for desiring configuration.

I was already thinking that, if for no other reason than backward compatibility, that I'd find a hybrid approach. Your idea of creating a strategy seems reasonable, but (at least on the surface) doesn't help with the simple case of simply wanting to specify an alternate String value to use...you'd still have to implement the strategy interface to even do the simplest thing. But, as I think about it, I suppose I could supply a default implementation and perhaps a corresponding PropertyEditor so that if you try to inject a String value into that strategy property it would inject it with the default implementation such that it would always return the given String. (In my head that makes sense, but I'm not so sure my fingers expressed it adequately to the keyboard...feel free to ask me to clarify.)

[Generic1]

To be clear again, ConnectController's job is to orchestrate the connection process, which is an authorization process. That said, the authorization process can be used as a form of authentication as well. ProviderSignInController is a Spring Social controller that can be used to orchestrate the connection process in such a way that the user ends up authenticated into your application.

I am not sure if I understood you in the right way: with ProviderSignInController it is possible to map/adapt the e.g. twitter account "data" into my local database and if a user logs in the second time only the logindata has to check against my web appl database?

Thanks!!!

[Generic1]

Hi again,

thanks for your patients first.
I would have one (last) question. I have tried to get it work with ProviderSigninController - it works fine exept of signInUrl.
I have configured the ProviderSignInController like above - all works fine but I will not be redirected to the twitter- JSP but always to the MyApp/signin - so I get 404, Resource not found.
My problem is that I have already a /signin- Controller so I must redirect to my home- page because I can't have a Controller which redirects /signin requests to /home.

I have once again uploaded my application. It can be found under http://www.file-upload.net/download-...PTest.zip.html
I would very grateful if you could help me once again.
Thanks a lot!
Generic

<bean id="providerSignInController" class="org.springframework.social.connect.web.ProviderSignInController">
            <constructor-arg ref="connectionFactoryLocator" />
            <constructor-arg ref="usersConnectionRepository" />
            <constructor-arg ref="mysignInAdapter" />
            <property name="signInUrl" value="twitter" />
</bean>