401 Unauthorized

[mschipperheyn]

Actually, not exactly

org.springframework.web.client.HttpClientErrorException: 401 Unauthorized
        at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:75)
        at org.springframework.web.client.RestTemplate.handleResponseError(RestTemplate.java:486)
        at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:443)
        at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:415)
        at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:391)
        at org.springframework.social.oauth1.OAuth1Template.exchangeForToken(OAuth1Template.java:195)
        at org.springframework.social.oauth1.OAuth1Template.fetchRequestToken(OAuth1Template.java:116)
        at org.springframework.social.connect.web.ConnectSupport.buildOAuth1Url(ConnectSupport.java:124)
        at org.springframework.social.connect.web.ConnectSupport.buildOAuthUrl(ConnectSupport.java:84)
        at org.springframework.social.connect.web.ProviderSignInController.signIn(ProviderSignInController.java:118) 

[mschipperheyn]

I'm just wondering if this has to do something with the calling domain.
I tested on my dev environment which uses a hosts file based :90 address which is different from the authorized domain. This worked fine each and every time.
The acceptance server is at Rackspace and uses .acc.domain as domain and this one actually has been added to the authorized domains @twitter. This fails each and every time.

[habuma]

When you say "authorized domain", do you mean the entries under the "@Anywhere domains" tab on Twitter? If so, then that shouldn't have anything to do with it. Those are for some of Twitter's Javascript widgets from their @Anywhere JS library. Even the callback URL in the application settings is flexible because ConnectController/ProviderSignInController will always send a callback URL to override the configured one.

In your stack trace, it appears to be failing when it gets the request token, via the call to OAuth1Template.fetchRequestToken(). At that point, the callback URL is the only thing passed in. So, either the OAuth1Template is misconfigured (because the TwitterConnectionFactory was given the wrong consumer key/secret) or the callback URL is bad.

I don't believe Twitter does anything with the callback URL at this point other than note it for future use--in fact, I've tested this with completely made-up URLs and it works fine. (I've even tested it with things that don't look like URLs, eg. "xxxxxx", and it still fetches a request token for me.) So, if I were guessing, I'd say something's not right about your TwitterConnectionFactory configuration and the consumer key/secret pair. If those are wrong, you'd definitely get a 401 at that point.

[mschipperheyn]

Based on your reply I think it may be because my web server adds slashes to rest urls without slashes and redirects. My redirect url was without slashes. Awesome, thanks for the info.

[mschipperheyn]

Nope, no luck. This is also reported

RestTemplate.handleResponseError(478) | POST request for "https://api.twitter.com/oauth/request_token" resulted in 401 (Unauthorized); invoking error handler

[iturpablo]

Hi,
I think Im having the same problem. It happen when i receive the twitter callback. the error happens in the following line

OAuthToken accessToken = oauthOperations.exchangeForAccessToken( new AuthorizedRequestToken(requestToken, oauthVerifier), null);

this is the url sent by twitter.
http://localhost:8080/xxx/j_spring_s...h_verifier=xxx

The error
GRAVE: Servlet.service() para servlet default lanzó excepción
org.springframework.web.client.HttpClientErrorExce ption: 401 Unauthorized
at org.springframework.web.client.DefaultResponseErro rHandler.handleError(DefaultResponseErrorHandler.j ava:75)
at org.springframework.web.client.RestTemplate.handle ResponseError(RestTemplate.java:486)
at org.springframework.web.client.RestTemplate.doExec ute(RestTemplate.java:443)
at org.springframework.web.client.RestTemplate.execut e(RestTemplate.java:415)
at org.springframework.web.client.RestTemplate.exchan ge(RestTemplate.java:391)


Does somebody know a work around??

[habuma]

iturpablo: Based on what you've said, it looks like you've gone through the authorization step and Twitter has done the callback to your app, which was handled by ConnectController. ConnectController then attempted to exchange the request token and verifier for the access token. But there's little else for me to go on to help you diagnose your problem.

At least on the surface, this doesn't appear to be a bug in either Spring Social or in Twitter's API, as I've just run through the same steps with Spring Social Showcase and had no troubles. Have you tried doing a Twitter connection with (unaltered) Spring Social Showcase? Is there anything you've done in your app that might contribute to this problem? Are the any runtime environment considerations that might've played a part here?

My advice is to go get the Spring Social Showcase and run it. Sign in as one of the built-in users and then try to connect with Twitter. If that works, then it must be something in your app. If it doesn't work, then there may be some runtime situation in play. I just can't say without knowing more.

[iturpablo]

Hi Habuma: Currently Im developing a project with JSF and with out spring MVC. I reproduce the problem in a simple jsf backing bean, here is the code and the behavior.

@ManagedBean(name="bean")
@ViewScoped
public class beanInfo implements Serializable {


private static final long serialVersionUID = 1L;



public beanInfo()
{ }
@PostConstruct
public void pageLoad()
{

ExternalContext eCntxt = FacesContext.getCurrentInstance().getExternalConte xt();
String oauthVerifier = (String)eCntxt.getRequestParameterMap().get("oauth _verifier");


TwitterConnectionFactory connectionFactory =
new TwitterConnectionFactory("9r75NyKnrmIzn6QvYzyEQ", "VHIphyAa47fN5k8IhsBFcMxqZBRwa6ib4GJdCdVcjnE") ;
OAuth1Operations oauthOperations = connectionFactory.getOAuthOperations();
OAuthToken requestToken = oauthOperations.fetchRequestToken("http://127.0.0.1:8080/EBIProject/faces/index.xhtml", null);
String authorizeUrl = oauthOperations.buildAuthorizeUrl(requestToken.get Value(), OAuth1Parameters.NONE);

if (!StringUtils.hasText(oauthVerifier))
{
//Primera Fase de la autenticación
try {
eCntxt.redirect(authorizeUrl);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return;

} else
{
// upon receiving the callback from the provider:
OAuthToken accessToken = oauthOperations.exchangeForAccessToken(
new AuthorizedRequestToken(requestToken, oauthVerifier), null);
Connection<Twitter> connection = connectionFactory.createConnection(accessToken);
}


}
The callback url -> http://127.0.0.1:8080/EBIProject/fac...QrNo9PdW0QOFPw

and the exception:
org.springframework.web.client.HttpClientErrorExce ption: 401 Unauthorized
at org.springframework.web.client.DefaultResponseErro rHandler.handleError(DefaultResponseErrorHandler.j ava:75)
at org.springframework.web.client.RestTemplate.handle ResponseError(RestTemplate.java:486)
at org.springframework.web.client.RestTemplate.doExec ute(RestTemplate.java:443)
at org.springframework.web.client.RestTemplate.execut e(RestTemplate.java:415)
at org.springframework.web.client.RestTemplate.exchan ge(RestTemplate.java:391)
at org.springframework.social.oauth1.OAuth1Template.e xchangeForToken(OAuth1Template.java:194)
at org.springframework.social.oauth1.OAuth1Template.e xchangeForAccessToken(OAuth1Template.java:133)
at ebimanager.model.beanInfo.pageLoad(beanInfo.java:6 1)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.faces.vendor.WebContainerInjectionProvider .invokeAnnotatedMethod(WebContainerInjectionProvid er.java:117)
at com.sun.faces.vendor.WebContainerInjectionProvider .invokePostConstruct(WebContainerInjectionProvider .java:99)
at com.sun.faces.mgbean.BeanBuilder.invokePostConstru ct(BeanBuilder.java:223)
at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder .java:105)
at com.sun.faces.mgbean.BeanManager.createAndPush(Bea nManager.java:409)
at com.sun.faces.mgbean.BeanManager.create(BeanManage r.java:269)
at com.sun.faces.el.ManagedBeanELResolver.resolveBean (ManagedBeanELResolver.java:244)
at com.sun.faces.el.ManagedBeanELResolver.getValue(Ma nagedBeanELResolver.java:116)
at com.sun.faces.el.DemuxCompositeELResolver._getValu e(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue (DemuxCompositeELResolver.java:203)
at org.apache.el.parser.AstIdentifier.getValue(AstIde ntifier.java:71)
at org.apache.el.parser.AstValue.getValue(AstValue.ja va:147)
at org.apache.el.ValueExpressionImpl.getValue(ValueEx pressionImpl.java:189)
at com.sun.faces.facelets.el.TagValueExpression.getVa lue(TagValueExpression.java:109)
at javax.faces.component.ComponentStateHelper.eval(Co mponentStateHelper.java:194)
at javax.faces.component.ComponentStateHelper.eval(Co mponentStateHelper.java:182)
at javax.faces.component.UIOutput.getValue(UIOutput.j ava:169)
at com.sun.faces.renderkit.html_basic.HtmlBasicInputR enderer.getValue(HtmlBasicInputRenderer.java:205)
at com.sun.faces.renderkit.html_basic.HtmlBasicRender er.getCurrentValue(HtmlBasicRenderer.java:355)
at com.sun.faces.renderkit.html_basic.HtmlBasicRender er.encodeEnd(HtmlBasicRenderer.java:164)
at javax.faces.component.UIComponentBase.encodeEnd(UI ComponentBase.java:875)
at javax.faces.component.UIComponent.encodeAll(UIComp onent.java:1763)
at javax.faces.component.UIComponent.encodeAll(UIComp onent.java:1759)
at javax.faces.component.UIComponent.encodeAll(UIComp onent.java:1759)
at com.sun.faces.application.view.FaceletViewHandling Strategy.renderView(FaceletViewHandlingStrategy.ja va:401)
at com.sun.faces.application.view.MultiViewHandler.re nderView(MultiViewHandler.java:131)
at com.sun.faces.lifecycle.RenderResponsePhase.execut e(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:1 01)
at com.sun.faces.lifecycle.LifecycleImpl.render(Lifec ycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServl et.java:594)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:169)
at org.apache.catalina.authenticator.AuthenticatorBas e.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:168)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:405)
at org.apache.coyote.http11.AbstractHttp11Processor.p rocess(AbstractHttp11Processor.java:964)
at org.apache.coyote.AbstractProtocol$AbstractConnect ionHandler.process(AbstractProtocol.java:515)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProce ssor.run(JIoEndpoint.java:302)
at java.util.concurrent.ThreadPoolExecutor$Worker.run Task(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:680)

The exception occurs at the OAuthToken accessToken = oauthOperations.exchangeForAccessToken(new AuthorizedRequestToken(requestToken, oauthVerifier), null); instruction.

Hope you can help me, I already did it with facebook api with out a problem dont know why twitter fails.

Thanks you soo much

[habuma]

I'm not a JSF expert, but from the looks of this code, it seems that you are trying to exchange a *new* request token for a verifier that was given using an *old* request token.

In the callback handling, you fetch the verifier from the request. This verifier came from authorizing a request token previously. But then you go fetch a new request token and use the new request token along with the verifier from the old request token to try to get an access token. That won't work and explains the 401.

The fetching of the request token should only happen in the primary phase and you should stow it away so that when you handle the callback you are working with the same request token for which the authorization (and verifier) was granted.

[iturpablo]

Yess!! you are totally right, I thought that the requestToken object was built the same every time.. sorry rocky mistake Ill try keeping the same token...

Thanks!!