I have been reading multiple articles on how to sniff and subsequently use the data obtained to interact with closed source apis recently.
I am concentrated on the tinder api since it seemed to me ample research had been done already on it, hence it would be easy to learn from.
http://ttcubicle.blogspot.com/2015/03/reverse-engineering-tinders-api.html
http://ec2-52-42-144-243.us-west-2.compute.amazonaws.com/tinder/
Althrough I managed to sniff the authentification between the tinder app on my phone and the server through fiddler, I am not able to actually simulate that login using curl on the command line
----- Below is the request send from my phone to the server --- for obvious reasons I changed my actual data ----
POST https://api.gotinder.com/auth HTTP/1.1
platform: android
User-Agent: Tinder Android Version 6.5.1
os-version: 23
Facebook-ID: 10151935000326599
Accept-Language: en
app-version: 1955
Content-Type: application/json; charset=utf-8
Content-Length: 257
Host: api.gotinder.com
Connection: Keep-Alive
Accept-Encoding: gzip
X-Auth-Token: ccXX9a-4a99c-4e32-8154-9b21asf5eec
{"facebook_token":"EAfasfasfasfN6solZAh8M3kwxsP1JzF6OBDocdNUEyxd8tsVCN6kWZA6fArZB0T5dZArmdVvKAXUuQZCOtoVZBPasfzUMz9RfFoSpEifEVm7bAIspEerbLKRgW3DCpHHuxVyZApr1koAHhIjCGtxUZAAZAtDvTTbayrkF","facebook_id":"111111119","locale":"en"}
My knowledge regarding POST / Headers and all of these things is still a bit shacky (thats why I am trying to re-enact) but from what I understand that next step should be to send a POST request with curl that sends the X-Auth-Token in the header and facebook_token and so on in the data part.
something like this:
curl -H "Content-Type: application/json" -H "X-Auth-Token: cc5555a-499c-4e32-8154-9b25555ec" -d '{"facebook_token":"EAAGasdpsBAEzbJDJdcHXLjKpDjN6solZAh8M3kwxsP1JzF6OBDocdNUEyxd8tsVCN6kWZA6fArZB0T5dZArmdVvKAXUuQZCOtoVZBPZBMTUJzUMz9RfFoSpEifEVm7bAIspEerbLKRgW3DCpHHuxVyZApr1koAHhIjCGtxUZAAZA555TTbayrkF","facebook_id":"101519555326599","locale":"en"}' https://api.gotinder.com/auth
However, no matter how I change the parameters around, I always get Errorcodes 500 or 401 thrown back at me. The maximum I can get is the server telling me that it excpects a facebook_token (which is obviously send in the data section)
Does anyone has experience with this sort of problem ?
Thank you
I just discovered phyton and... holyshit i am in love!
payloadauth = {"facebook_token":"EAA xxxxxx
header1 = { 'platform': 'android','User-Agent': 'Tinder, 'X-Auth-Token':'cblabla
with requests.Session() as c:
response = c.post('https://api.gotinder.com/auth',data=payloadauth)
response = c.get('https://api.gotinder.com/recs/core?locale=en', headers=header1)
print(response.json())
four lines of code...
Related
First time asking a question here. I'm a beginner at this, but i'm truly stumped at the problem i'm facing.
Browsers in use:
Safari and Firefox (both on Mac OS Sierra)
Firefox (Linux - Ubuntu 16.04.2)
I am registered as an Uber Developer and have registered an App in the Dashboard. I'm only using the Server Token for authentication at the moment. In the Dashboard, I have set the following entries in the "Authorizations" tab of the App for CORS (Optional URI for CORS Support):
http://localhost:8000 <-- web server in my PC
https://subdomain.mydomain.com <--- remote web server
A few months ago i created a web app using HTML, CSS and JS (with Jquery v2.2.4) to play around with the Ride Estimates API and was able to get it to report data for many locations in my area successfully. Somehow it no longer works. I'm trying to fix that and improve the functionality. However, i just can't get past the initial query to the API because of CORS issues that were not existent before.
My API URL is:
https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}
When i paste that in the address bar of the browser i get valid JSON:
{"prices":[{"localized_display_name":"uberX","distance":1.58,"display_name":"uberX","product_id":"811c3224-5554-4d29-98ae-c4366882011f","high_estimate":3,"surge_multiplier":1.0,"minimum":2,"low_estimate":2,"duration":420,"estimate":"2-3\u00a0$","currency_code":"USD"},{"localized_display_name":"X English","distance":1.58,"display_name":"X English","product_id":"8fe2c122-a4f0-43cc-97e0-ca5ef8b57fbc","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"uberXL","distance":1.58,"display_name":"uberXL","product_id":"eb454d82-dcef-4d56-97ca-04cb11844ff2","high_estimate":4,"surge_multiplier":1.0,"minimum":3,"low_estimate":3,"duration":420,"estimate":"3-4\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber Black","distance":1.58,"display_name":"Uber Black","product_id":"ba49000c-3b04-4f54-8d50-f7ae0e20e867","high_estimate":6,"surge_multiplier":1.0,"minimum":4,"low_estimate":4,"duration":420,"estimate":"4-6\u00a0$","currency_code":"USD"},{"localized_display_name":"Uber SUV","distance":1.58,"display_name":"Uber SUV","product_id":"65aaf0c2-655a-437d-bf72-5d935cf95ec9","high_estimate":7,"surge_multiplier":1.0,"minimum":5,"low_estimate":5,"duration":420,"estimate":"5-7\u00a0$","currency_code":"USD"}]}
I then proceed to set up JS (w/ JQuery) code in webpage...
var url = "https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}";
$.getJSON(url, function(result){
console.log(result);
});
Uploading the HTML and JS to my remote web server and then loading the webpage in any of my browsers yields a 200 status from Uber API. However, the console log shows CORS blocking my request (PROBLEM #1):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.uber.com/v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********}. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Then, in the Inspector view of both Mac Browsers, under the Network / Resources areas, i see the 200 Status message from the GET request. However, along with the Response message (PROBLEM #2):
SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data
The Request Headers are:
GET /v1/estimates/price?start_latitude=8.969145&start_longitude=-79.5177675&end_latitude=8.984104&end_longitude=-79.517467&server_token={*********SERVER*TOKEN**********} HTTP/1.1
Host: api.uber.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://subdomain.domain.com/Uber/index.html
Origin: https://subdomain.domain.com
Connection: keep-alive
The Response Headers are:
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 19 Mar 2017 22:26:31 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Content-Geo-System: wgs-84
Content-Language: en
X-Rate-Limit-Limit: 2000
X-Rate-Limit-Remaining: 1998
X-Rate-Limit-Reset: 1489964400
X-Uber-App: uberex-nonsandbox, optimus, migrator-uberex-optimus
Strict-Transport-Security: max-age=604800
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
In Firefox for Linux i sometimes don't get the Syntax Error; i always seem to get it on the Mac Browsers. In Linux, when i do get that error, then clicking on the "Edit and Resend" Headers button (resending the Headers but without really editing the Headers), the Syntax Error disappears and the Response text actually shows the Uber API Object that is supposed to be there... but i still get the CORS Blocked message on the Console Log. I really don't understand why this is, but it seems contradictory. In the end, i am unable to get to use the API data that, using the same method months ago, i could get for several dozens of locations.
I have looked for answers in similar questions but so far have found none that apply to my case. Any help will be greatly appreciated. Getting really frustrated... really stuck here.
This issue was caused by the API not including the header correctly. This issue is resolved and the api is now working as expected. Also, the allow origin header will only be returned in a response if an origin is specified in the request.
Problem
I'm testing a wsdl application with a remote server, so I can't have any influence on the requesting mechanism.
While testing with it, I get this log messages.
DEBUG:spyne.protocol.soap.soap11:ValueError: Deserializing from unicode strings
with encoding declaration is not supported by lxml.
DEBUG:spyne.protocol.xml:Validated ? False
40.50.60.70 - - [14/Jul/2016 16:58:42] "POST /?WSDL HTTP/1.1" 500 480
So the problem seems to be, that my remote server doing it's requests in a utf-8 encoded string, but I'm not able to reproduce it on my local machine. There I'm doing this with curl, which has a charset=utf-8 encoding in it's header and a input xml, wich has encoding='UTF-8' in it's`-tag too.
$ curl -X POST -H "Content-Type: text/xml; charset=utf-8" -d #request.xml
http://localhost:8000 > response.xml
Approaches
I tried to set an event_listener at the process which builds the wsdl, to maybe get a chance to manipulate the input string with ctx.in_string or something else.
MyService.event_manager.add_listener('wsdl_document_built', _on_wsdl_document_built)
MyService.event_manager.add_listener('document_built', _on_document_built)
application.event_manager.add_listener('wsdl_document_built', _on_wsdl_document_built)
application.event_manager.add_listener('document_built', _on_document_built)
But there was no execution of my added functions.
Also i searched unseccessful the docs for a type of configuration, to pre decode it.
So my question is how to force some kind of encoding of the incoming request xml?
What would be the best way to post data to Meteor's MongoDB collection ?
I tried initially using the Postman chrome extension, command-line tool like curl but did not find any luck.
The curl command that I use is :
curl -i -X POST -H "Content-Type: application/json" -d '{"hacker":"fromcurl","score":100}' http://localhost:3000/players
OUTPUT:
HTTP/1.1 200 OK
vary: Accept-Encoding
content-type: text/html; charset=utf-8
date: Tue, 17 May 2016 00:37:44 GMT
connection: keep-alive
transfer-encoding: chunked
<!DOCTYPE html>
<html>
PS : players is the collection/table name
Take a look at DDP, Meteor uses this protocol to communicate between client and server. DDP is simple and based on JSON. Meteor’s DDP currently based on WebSockets and SockJS. That's very helpful. I have a case that Websocket cannot work in local LAN network but the connection fall back to SockJS, then everything work fine, that's great!
An example implement DDP communication between Meteor and Python.
Simply create a Meteor method:
Meteor.methods({
clientProcessData: function (data) {
console.log(data);
// Meteor post data to MongoDB code here
},
Follow the instructions from https://github.com/hharnisc/python-meteor to install python-meteor client and connect to Meteor server.
You can call Meteor method from Python by:
client.call('clientProcessData', ["This is a test"], callback_function)
Not sure are there any other DDP clients of other programming language, but in my case, python works great!
// Update: There are many of them, but I'm so new here that afraid of posting external link, so please do a simple "DDP client" search on google.
consider a web service written in play, which excepts POST request (for uploads). now, when testing this with a medium size image (~75K) I've found out a strange behaviour. well, code speaks more clearly than long explanations, so:
$ curl -vX POST localhost:9000/path/to/upload/API -H "Content-Type: image/jpeg" -d #/path/to/mascot.jpg
* Hostname was NOT found in DNS cache
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> POST /path/to/upload/API HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
> Content-Type: image/jpeg
> Content-Length: 27442
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Content-Length: 16
<
* Connection #0 to host localhost left intact
{"success":true}
as you can see, curl decides to add the header Content-Length: 27442, but it's not true, the real size is 75211, and in play, I indeed got a body in size only 27442. of coarse, this is not the intended behaviour. so I tried a different tool, instead of curl I used the POST tool from libwww-perl:
cat /path/to/mascot.jpg | POST -uUsSeE -c image/jpeg http://localhost:9000/path/to/upload/API
POST http://localhost:9000/path/to/upload/API
User-Agent: lwp-request/6.03 libwww-perl/6.05
Content-Length: 75211
Content-Type: image/jpeg
200 OK
Content-Length: 16
Content-Type: application/json; charset=utf-8
Client-Date: Mon, 16 Jun 2014 09:21:00 GMT
Client-Peer: 127.0.0.1:9000
Client-Response-Num: 1
{"success":true}
this request succeeded. so I started to pay more attention to the differences between the tools. for starter: the Content-Length header was correct, but also, the Expect header was missing from the second try. I want the request to succeed either way. so the full list of headers as seen in play (via request.headers) is:
for curl:
ArrayBuffer((Content-Length,ArrayBuffer(27442)),
(Accept,ArrayBuffer(*/*)),
(Content-Type,ArrayBuffer(image/jpeg)),
(Expect,ArrayBuffer(100-continue)),
(User-Agent,ArrayBuffer(curl/7.35.0)),
(Host,ArrayBuffer(localhost:9000)))
for the libwww-perl POST:
ArrayBuffer((TE,ArrayBuffer(deflate,gzip;q=0.3)),
(Connection,ArrayBuffer(TE, close)),
(Content-Length,ArrayBuffer(75211)),
(Content-Type,ArrayBuffer(image/jpeg)),
(User-Agent,ArrayBuffer(lwp-request/6.03 libwww-perl/6.05)),
(Host,ArrayBuffer(localhost:9000)))
So my current thoughts are: the simpler perl tool used a single request, which is bad practice. the better way would be to wait for a 100 continue confirmation (especially if you gonna' upload a several GB of data...). curl would continue to send data until it receives a 200 OK or some bad request error code. So why play sends the 200 OK response without waiting for the next chunk? is it because curl specifies the wrong Content-Length? if it's wrong at all... (perhaps this refers to the size of the current chunk?).
so where's the problem lies? in curl or in the play webapp? and how do I fix it?
the problem was in my curl command. I used the -d argument, which is a short for --data or --data-ascii, when I should have used --data-binary argument.
I am using curl for sending a POST HTTP message to my server. At Server side I am opening a socket and reading the data by using following code
recv(socket_Fd, (void *)ucBuffer, (size_t)((sizeof(ucBuffer) - 1)), NULL);
I am able to get the header of the POST message but in message body I am getting only one line , rest are missing.
Data I am receiving at server end.
POST /info HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.168.0.57:10000
Accept: */*
Content-Length: 356
Content-Type: application/x-www-form-urlencoded
Bhupesh Bhargava
In message header it's showing right content length but message body is missing. Any idea where I am doing wrong.
curl command I am using
curl --data-binary #/home/bhupesh/data_save2 http://192.168.0.57:10000/info
The curl command seems to be OK and if we go by the documentation here, the following should be true.
Data is posted in a similar manner as --data-ascii does, except that
newlines are preserved and conversions are never done.
So, this leaves us with the fact that there should be a problem in your Server implementation. It is not quite sure how you are getting the received stuff at the server, but you should be careful about sequencing what you receive by yourself. Here is an example how you could do that.