Oauth failing on Twitter since yesterday

[sharathrocks]

Since yesterday, the Signin with Twitter on my web-app (currently in development) is failing.
It was working fine till a few days back. My application requests read only access from the user’s account.
One more thing I noticed was that the signin was failing on the following site also:
sentiment140.com

But it is working fine on pintrest.

Any changes on Twitter which might be causing this problem?

P.S. I haven’t changed any code related to oauth on the application. So my guess is that it should be fine on the application end.

[alecmgo]

I run sentiment140.com and I see the following error in the logs:

/signin 403:The request is understood, but it has been refused. An accompanying error message will explain why. This code is used when requests are being denied due to update limits (https://support.twitter.com/articles/15364-about-twitter-limits-update-api-dm-and-following).

Relevant discussions can be found on the Internet at:
http://www.google.co.jp/search?q=10f5ada3 or
http://www.google.co.jp/search?q=e574402b
TwitterException{exceptionCode=[10f5ada3-e574402b], statusCode=403, message=null, code=-1, retryAfter=-1, rateLimitStatus=null, version=3.0.3}
at twitter4j.internal.http.HttpClientImpl.request(HttpClientImpl.java:177)
at twitter4j.internal.http.HttpClientWrapper.request(HttpClientWrapper.java:61)
at twitter4j.internal.http.HttpClientWrapper.post(HttpClientWrapper.java:98)
at twitter4j.auth.OAuthAuthorization.getOAuthRequestToken(OAuthAuthorization.java:122)
at twitter4j.auth.OAuthAuthorization.getOAuthRequestToken(OAuthAuthorization.java:104)
at twitter4j.TwitterBaseImpl.getOAuthRequestToken(TwitterBaseImpl.java:281)
at com.twittersentiment.web.SigninServlet.doGet(SigninServlet.java:31)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at com.googlecode.objectify.cache.AsyncCacheFilter.doFilter(AsyncCacheFilter.java:59)
at com.googlecode.objectify.ObjectifyFilter.doFilter(ObjectifyFilter.java:49)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.ParseBlobUploadFilter.doFilter(ParseBlobUploadFilter.java:125)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.runtime.jetty.SaveSessionFilter.doFilter(SaveSessionFilter.java:35)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.JdbcMySqlConnectionCleanupFilter.doFilter(JdbcMySqlConnectionCleanupFilter.java:57)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:266)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:146)
at com.google.apphosting.runtime.JavaRuntime$RequestRunnable.run(JavaRuntime.java:439)
at com.google.tracing.TraceContext$TraceContextRunnable.runInContext(TraceContext.java:483)
at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:490)
at com.google.tracing.TraceContext.runInContext(TraceContext.java:777)
at com.google.tracing.TraceContext$DoInTraceContext.runInContext(TraceContext.java:754)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:345)
at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:337)
at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:487)
at com.google.apphosting.runtime.ThreadGroupPool$PoolEntry.run(ThreadGroupPool.java:251)
at java.lang.Thread.run(Thread.java:679)

The code path causing this exception requests a token and has worked fine for several months. When I look at the documentation for rate limits, it doesn’t mention anything about constraints on requesting tokens. Could anyone provide guidance?

Thanks,
Alec

[vincentisambart]

Since last week, api.twitter.com requires HTTPS. You might want to update the library you are using to call the Twitter API.

[sharathrocks]

@vincentisambart: Thanks a lot. I had not read the header on the dev page which said that starting Jan 14th all HTTP traffic would be blacked out. Thank you very much. I used SSL and the app’s running now.

[sharathrocks]

Using https URL’s in authorize, request token and access token URL’s as mentioned below by @vincentisambart worked for me. I use grails oauth plugin (which internally uses the scribe plugin) for authentication. It was a matter of changing the config (https://github.com/fernandezpablo85/scribe-java/blob/master/src/main/java/org/scribe/builder/api/TwitterApi.java) to use SSL URL’s.
Twitter4j will also have something similar I guess…