I've created an android app using twitter4j.
None of the api calls can authenticate when on 3g, but work perfectly when on wi-fi.
What could be the problem?
I've tested this extensively and can confirm this is only a problem on Android 4.0 (ICS) devices. Why, I'm unsure yet, though some parts of HttpURLConnection have changed in 4.0, so some of these changes have made twitter4j incompatible.
I thought it may have been this:
Android 4.0 ICS turning HttpURLConnection GET requests into POST requests
but after analysing the requests with tcpdump it seems like it is in fact making a valid GET, but for some reason, the twitter api still says it's a bad request..
GET /1/users/show.json?include_entities=true&user_id=6842472 HTTP/1.1
Authorization: OAuth oauth_consumer_key="<redacted>",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1331150787",oauth_nonce="2157367237",oauth_version="1.0",oauth_token="<redacted>",oauth_signature="<redacted>"
Accept-Encoding: gzip
X-Twitter-Client-URL: http://twitter4j.org/en/twitter4j-2.2.5.xml
User-Agent: twitter4j http://twitter4j.org/ /2.2.5
X-Twitter-Client-Version: 2.2.5
X-Twitter-Client: Twitter4J
Host: api.twitter.com
Connection: Keep-Alive
HTTP/1.1 400 Bad Request
Date: Wed, 07 Mar 2012 20:06:30 GMT
Status: 400 Bad Request
X-RateLimit-Class: api
X-RateLimit-Reset: 1331153824
X-Revision: DEV
Last-Modified: Wed, 07 Mar 2012 20:06:30 GMT
X-Frame-Options: SAMEORIGIN
X-Transaction: a0bf805e990a5c79
Content-Type: application/json; charset=utf-8
X-RateLimit-Remaining: 0
X-RateLimit-Limit: 150
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
X-Runtime: 0.00742
X-MID: 2295d07237fcb4763f7f54d2bf46e27dd40e022f
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Vary: Accept-Encoding
Server: tfe
Transfer-Encoding: chunked
Connection: close
Content-Encoding: gzip
Set-Cookie:
...
Unless someone can find what it is in ICS/HttpURLConnection that is breaking this the only workaround I can see is to write an alternate backend for twitter4j that uses HttpClient instead of HttpURLConnection, which is exactly what I plan to do.
EDIT: So I wrote the a client backend for twitter4j that uses the apache httpclient and it suffers from the exact same problem!! Some more sleepless hours and wireshark has brought me to the following very handy solution, that actually works:
Initialise your twitter4j instance like this:
ConfigurationBuilder configurationBuilder = new ConfigurationBuilder();
configurationBuilder.setOAuthConsumerKey(Const.CONSUMER_KEY);
configurationBuilder.setOAuthConsumerSecret(Const.CONSUMER_SECRET);
configurationBuilder.setUseSSL(true);
Configuration configuration = configurationBuilder.build();
twitter = new TwitterFactory(configuration).getInstance();
The setUseSSL(true) is the magic line.
Related
I have developed ReactNative mobile application, When I run security tests using [ImmuniWeb] report shows me that my application makes post request to 'https://www.googleapis.com/experimentsandconfigs/v1/getExperimentsAndConfigs'1 I have not used any of the google analytical tools or any other google cloud services in my application.
One of the Example request is traced as below.
Date/Time: 16.05.2020 17:27 CEST
Requested URL: https://www.googleapis.com/experimentsandconfigs/v1/getExperimentsAndConfigs
Requested HTTP Headers:
User-Agent: Android/com.google.android.gms/16089022 (generic_x86 OSM1.180201.031); gzip
content-length: 1069
content-type: application/x-protobuf
Host: www.googleapis.com
Connection: Keep-Alive
Accept-Encoding: gzip
Response HTTP Headers:
Content-Type: application/octet-stream
Vary: Accept-Encoding
Date: Sat, 16 May 2020 15:27:24 GMT
Expires: Sat, 16 May 2020 15:27:24 GMT
Cache-Control: public, max-age=0
X-Content-Type-Options: nosniff
Server: sffe
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Alt-Svc: h3-27=":443"; ma=2592000,h3-25=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Transfer-Encoding: chunked
content-length: 49581
I have also created dummy app to check the same it is reporting the same issue in security report.
you can see the full report here. Security Report
Can anyone please help me solving this? Thanks in advance.
Just launched a new AngluarJs mobile site that passed developer and QA testing and now live a small percentage of users are getting errors(could not find expected value).
Tracked this down to Android Chrome users that have the "Reduce Data Usage" setting toggled ON which then routes requests through Google's data compression proxy.
The reason this is generating an error is that the server does not receive the custom http header that is passed from the client. We can clearly see that the Google proxy is stripping it.
How can we stop Google's proxy stripping custom headers and is this expected behaviour? I could not find anything related in the developer Docs.
Google's Compression Proxy doesn't strip response headers, at least those beginning with X-. See below the response headers of this web page using Compression Proxy:
cache-control: public, max-age=60
content-encoding: gzip
content-length: 15283
content-type: text/html; charset=utf-8
date: Sat, 31 Jan 2015 20:17:30 GMT
expires: Sat, 31 Jan 2015 20:18:30 GMT
last-modified: Sat, 31 Jan 2015 20:17:30 GMT
server: GFE/2.0
status: 200 OK
vary: *
version: HTTP/1.1
via: 1.1 Chrome-Compression-Proxy
x-frame-options: SAMEORIGIN
x-original-content-length: 15283
x-request-guid: 719ab2fb-7f3b-4296-b6fd-497997ffe761
So the possible solution is to use X-SiteHost header name.
I have a little crazy problem. I have an IIS7 where I need to post a formular via POST, also I need to authenticate via NTLM and all this stuff thrue a SSL connection. So far I managed it to connect to the server and post my data.
After the POST I'll get on success a 302 response which redirects me to a second page. The DefaultHttpClient connects to the webserver does the auth and post the data. So far everything works. But now the client closes the connection and opens a second connection (this behavoir is anying me) but this is not my problem. On the second connection the client forget how to auth on the IIS and breaks with the 401 auth error.
So far I can see this is a fixed bug in the source of DefaultHttpClient, but Android seems to use an older version of this lib. How can I fix that bug which seems to be on every android device on the world?
Here are the relevant parts of my communication:
POST /login/ HTTP/1.1
Content-Length: 21
Content-Type: application/x-www-form-urlencoded
Host: example.com
Connection: Keep-Alive
Cookie: ASPSESSION...
[the post data]
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: NTLM
Content-Length: 1344
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
...
</html>
POST /login/ HTTP/1.1
Content-Length: 21
Content-Type: application/x-www-form-urlencoded
Host: example.com
Connection: Keep-Alive
Cookie: ASPSESSION...
Authorization: NTLM ABC...==
[the post data]
HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
WWW-Authenticate: NTLM ABC...DEF
Content-Length: 341
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Not Authorized</TITLE>...</HTML>
POST /login/ HTTP/1.1
Content-Length: 21
Content-Type: application/x-www-form-urlencoded
Host: example.com
Connection: Keep-Alive
Cookie: ASPSESSION...
Authorization: NTLM ABC...DEF
[the post data]
HTTP/1.1 302 Moved Temporary
Cache-Control: private,no-cache
Pragma: no-cache
Content-Length: 31
Content-Type: application/json; Charset=UTF-8
Expires: Fri, 07 Dec 2012 07:01:00 GMT
Location: /login/step2.asp
Server: Microsoft-IIS/7.5
Set-Cookie: [...] path=/login/; HttpOnly;
Persistent-Auth: true
[some response]
--- now does the connetion close and a second https connection is opened ---
GET /login/step2.asp HTTP/1.1
Host: example.com
Connection: Keep-Alive
Cookie: ASPSESSION...
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: NTLM
Content-Length: 1344
--- and the connection closes again ---
Does you know a way to fix that?
Why don't you just get the libs of the new versions of DefaultHttpClient and include that in your project?
Well this is no solution just a workaround for my problem, but this may help. I override the createClientRequestDirector function in the DefaultHttpClient where I handle the redirect by my own.
The cause for the connection closing is that I play with the host names, so I connect to the IP and not the host name. The result is that the client looks while redirection if the connection can be reused by comparing the source and destination url. So it will be compaired https://www.example.com/ with https://127.0.0.1/ which failes and the conenction will be closed.
My solution is that I check this part by my own. And if the hostname and IP matches I'll return the last used IP. The result is that the connection can be reused and I don't run in the bug linked above.
I'm trying to get an access token to use the Google Web Play API, but it won't work, and it won't give a helpful error message, and Google doesn't provide a lick of support.
https://developers.google.com/android-publisher/authorization
Client ID for web applications
Client ID: 37625491467222.apps.googleusercontent.com
Email address: 37625491467222#developer.gserviceaccount.com
Client secret: XB5gwFt8w29Fs34540gr9urEGEmUHCLI
Redirect URIs: http://www.kizbit.com/oauth2callback
JavaScript origins: http://www.kizbit.com
Refresh token:
http://www.kizbit.com/oauth2callback?code=4/IAoP7JxYfe82KsuUwQRWQw2na_vreOM.MtjvGJqCG3IYshQV0ieZDArkfr1icAI
[root#308321 ~]# cat authcode.txt
grant_type=authorization_code&code=4%2FIAoP7JxYfe82KsuUwQRWQw2na_vreOM.MtjvGJqCG3IYshQV0ieZDArkfr1icAI&client_id=37625491467222.apps.googleusercontent.com&client_secret=XB5gwFt8w29Fs34540gr9urEGEmUHCLI&redirect_uri=http%3A%2F%2Fwww.kizbit.com%2Foauth2callback
[root#308321 ~]# wget -S --post-file=authcode.txt https://accounts.google.com/o/oauth2/token
--2012-06-28 01:08:37-- https://accounts.google.com/o/oauth2/token
Resolving accounts.google.com... 2001:4860:b007::54, 74.125.142.84
Connecting to accounts.google.com|2001:4860:b007::54|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.0 400 Bad Request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Thu, 28 Jun 2012 05:08:40 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
2012-06-28 01:08:
37 ERROR 400: Bad Request.
I know you're not supposed to give out keys but it doesn't matter because it doesn't work!
The refresh token doesn't work either.
Not encoding the file doesn't work either:
[root#308321 ~]# cat authcode2.txt
grant_type=authorization_code
code=4/IAoP7JxYfe82KsuUwQRWQw2na_vreOM.MtjvGJqCG3IYshQV0ieZDArkfr1icAI
client_id=37625491467222.apps.googleusercontent.com
client_secret=XB5gwFt8w29Fs34540gr9urEGEmUHCLI
redirect_uri=http://www.kizbit.com/oauth2callback
[root#308321 ~]# wget -S --post-file=authcode2.txt https://accounts.google.com/o/oauth2/token
--2012-06-28 01:33:44-- https://accounts.google.com/o/oauth2/token
Resolving accounts.google.com... 2001:4860:b007::54, 74.125.142.84
Connecting to accounts.google.com|2001:4860:b007::54|:443... connected.
HTTP request sent, awaiting response...
HTTP/1.0 400 Bad Request
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Date: Thu, 28 Jun 2012 05:33:47 GMT
Content-Type: application/json
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Server: GSE
2012-06-28 01:33:44 ERROR 400: Bad Request.
I don't know how I solved this. Some possible things I may have done:
Make the access token request from the same IP as the web page authorization request to get the code.
Use wget -dSO- --post-file to debug.
Make the access token request very quickly after the web page authorization. Maybe the code only lasts 10m?
Add more IPs to the Javascript origins in the Google API Console.
Re-URL encode the POST file and strip off any trailing newlines.
Anyways, once I got the access token and the all-so-important refresh token, I'm was good.
I'm trying to develop a android app that using push notifications. While using the Tomcat Server I'm able to successfully register and push notification to a device. I get the response back as:
HTTP/1.1 200 OK [Connection: Keep-Alive, Transfer-Encoding: chunked, Content-Type: text/plain, Cache-control: no-cache, no-store, Pragma: no-cache, Expires: Mon, 01-Jan-1990 00:00:00 GMT, Date: Wed, 11 Apr 2012 17:25:31 GMT, X-Content-Type-Options: nosniff, X-XSS-Protection: 1; mode=block, Server: GSE]
But when trying to implement the same code using WebSphere, I encounter the following error for registration:
Exception :Exception in executing http post request for Android Registration: HTTP/1.1 200 Error
Can anyone point out on what I may be missing between these two different environments?
I would start by using curl and/or network monitoring/logging to lay out exactly what request is being sent to the C2DM servers.
It certainly seems odd WebSphere is receiving a 200, but showing it as an error. That's where I'd be looking.