I'm trying to debug an issue calling the Twitter API (it works on my localhost, but doesn't work from a Server 2012 R2 build). But i don't think it's an issue on Twitter's side.
Anyway, to strip it down to a basic example, if i use Fiddler on my local Windows 10 desktop to POST to this endpoint: https://api.twitter.com/oauth/request_token
With this header data:
User-Agent: Fiddler
Authorization: OAuth oauth_consumer_key="xx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1654005734",oauth_nonce="yy",oauth_version="1.0",oauth_signature="zz"
Accept: */*
Host: api.twitter.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 0
I 'successfully' receive a HTTP 401, which is expected (because the info in my request is obviously inaccurate for this forum). Great.
But if i POST the exact same data using Fiddler on my Server 2012 R2 build, I get an HTTP 404?
Can anybody explain why this might be? I don't see any errors in Wireshark related to certificates or ciphers? I'm stumped....
UPDATE
I can reproduce the same issue with PowerShell like so:
Invoke-WebRequest -Headers #{"Authorization" = 'OAuth oauth_consumer_key="xx",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1654005734",oauth_nonce="yy",oauth_version="1.0",oauth_signature="zz"' } `
-Method POST `
-Uri https://api.twitter.com/oauth/request_token
I've finally got it working after days of debugging. It has something to do with Schannel/TLS/Cipher suites, but I'm not exactly sure what the specific fix was. I hope this helps somebody and saves a few days of pain.
https://www.alkanesolutions.co.uk/2022/06/07/twitter-api-giving-http-404-not-found-when-requesting-a-token/
Related
I'm attempting to get my App-Only bearer token from the Twitter Oauth2 API. Depending on how I do it, I get either error 400 (Bad Request) or 503 (Service Temporarily Unavailable). I'm stumped.
Attempt 1 was via a HTTPS socket (in Xojo, if you must know); when that failed I dropped down to a raw SSL socket, so that I know exactly what I'm sending. I'm sending this (with the credentials ellided here):
POST /oauth2/token HTTP/1.1
Host: api.twitter.com
User-Agent: My Twitter App v1.0.23
Authorization: Basic MUs1NGpvd (...stuff deleted...) MmpxeQ==
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-length: 29
Accept-Encoding: gzip
grant_type=client_credentials
This request is modeled directly after the one in the docs. It produces a 400 (Bad Request) error code.
Then I decided to try curl (again, credentials ellided):
curl -i -d 'grant_type=client_credentials' -H 'Authorization: Basic MUs1NGpv (...blah blah...) mpxeQ==' -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8' 'https://api.twitter.com/oauth2/token'
And this produces a 503 status code every time.
My credentials are just the Base64 version of my API key and secret, joined by a colon. The same key and secret work fine when tested with STTwitterDemoOSX. I'm almost (but not quite) desperate enough to use WireShark to see what that app is sending. But there must be something simple I'm doing wrong. Any ideas?
Oops. I found the problem, at least with the curl attempt: somehow a line break snuck into my authorization string without my noticing. When I take the line break out, it works.
Apologies for the noise (but maybe this will help someone else someday).
I am trying to send data from an arduino to a web server (LAMP) using the ESP8266 module, when I do a POST to a local network server the server receives the data and returns 200, however, when I post to an external server
(Hosting or google cloud) it registers error 400 in the Apache log and returns nothing, but when I do the same type of request by Postman everything is fine, because of this I do not know if it is my fault when mounting or executing the request or if Is some block on the external servers because the http server in my network works.
I'm using this lib to work with ESP: https://github.com/itead/ITEADLIB_Arduino_WeeESP8266
This is the request string:
POST /data/sensor_test.php HTTP/1.1
Host: xxxxxxxxx.com
Accept: */*
Content-Length: 188
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
temperatureAir1=19.70&humidityAir1=82.30&temperatureAir2=19.40&humidityAir2=78.60&externalTemperature=19.31&illumination05=898&illumination10=408&humiditySoilXD28=6&humiditySoilYL69=5
I found the problem, when I concatenated the strings that make up the request I was doing line breaks with \n, I switched to \r\n and it worked!
The amount of bytes really is with error, I am seeing to correct, but the good thing is that now the request is right.
Hi I am trying to setup an api to allow a 3rd parties webhooks a destination to post application/x-www-form-urlencoded.
I have only ever worked with json and xml with the webapi.
Do I need to create a custom mediatype to accept this or should it work by default?
Any suggestions would be appreciated.
UPDATE
I took a look at the example provided however I am still not to sure an example of the data the webhook will send to my api looks like.
How am I meant to setup my controller to accept this?
POST /some-path HTTP/1.1
Host: your.host.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 2837
Connection: keep-alive
Accept: /
environment=prod&domain_prefix=example&type=product.update&payload=%7B%22id%22%3A%229fe945bc-2d20-11e2-8057-080027706aa2%22%2C%22retailer_id%22%3A%229a5521c3-2d20-11e2-8057-080027706aa2%22%2C%22sku%22%3A%229416050901074%22%2C%22handle%22%3A%221000001%22%2C%22source%22%3A%22USER%22%2C%22active%22%3A%221%22%2C%22name%22%3A%22Ginger+Beer%22%2C%22description%22%3A%22%3Cp%3EA+delicious+ginger+beer+that+is+both+refreshing+and+good+value+for+money.%3C%5C%2Fp%3E%22%2C%22supplier%22%3A%7B%22id%22%3A%229fc84329-2d20-11e2-8057-080027706aa2%22%2C%22retailer_id%22%3A%229a5521c3-2d20-11e2-8057-080027706aa2%22%2C%22name%22%3A%22Brewer+Supplies+Ltd.%22%2C%22description%22%3A%22We+supply+all+things+brewed%5Cn%22%2C%22source%22%3A%22USER%22%7D%2C%22brand%22%3A%7B%22id%22%3A%229fb8e69d-2d20-11e2-8057-080027706aa2%22%2C%22name%22%3A%22Vaughan%27s+Ginger+Beer+Brewing+Company%22%7D%2C%22inventory%22%3A%5B%7B%22product_id%22%3A%229fe945bc-2d20-11e2-8057-080027706aa2%22%2C%22outlet_id%22%3A%229aee412b-2d20-11e2-8057-080027706aa2%22%2C%22attributed_cost%22%3A%221%22%2C%22count%22%3A%2222%22%2C%22reorder_point%22%3A%2212%22%2C%22restock_level%22%3A%2240%22%7D%2C%7B%22product_id%22%3A%229fe945bc-2d20-11e2-8057-080027706aa2%22%2C%22outlet_id%22%3A%229ae97219-2d20-11e2-8057-080027706aa2%22%2C%22attributed_cost%22%3A%221%22%2C%22count%22%3A%2214%22%2C%22reorder_point%22%3A%226%22%2C%22restock_level%22%3A%2220%22%7D%5D%2C%22price_book_entries%22%3A%5B%7B%22id%22%3A%22a1098b59-2d20-11e2-8057-080027706aa2%22%2C%22product_id%22%3A%229fe945bc-2d20-11e2-8057-080027706aa2%22%2C%22price%22%3A%222.00%22%2C%22tax%22%3A%220.25%22%2C%22type%22%3A%22BASE%22%2C%22customer_group_id%22%3A%229b097e69-2d20-11e2-8057-080027706aa2%22%2C%22customer_group_name%22%3A%22All+Customers%22%2C%22tax_id%22%3A%229a025ff0-2d20-11e2-8057-080027706aa2%22%2C%22tax_name%22%3A%22NZ+GST%22%2C%22tax_rate%22%3A%220.150000%22%7D%2C%7B%22id%22%3A%22a1318cf0-2d20-11e2-8057-080027706aa2%22%2C%22product_id%22%3A%229fe945bc-2d20-11e2-8057-080027706aa2%22%2C%22price%22%3A%221.90%22%2C%22tax%22%3A%220.24%22%2C%22type%22%3A%22GENERAL%22%2C%22customer_group_id%22%3A%229b097e69-2d20-11e2-8057-080027706aa2%22%2C%22customer_group_name%22%3A%22All+Customers%22%2C%22tax_id%22%3A%229a025ff0-2d20-11e2-8057-080027706aa2%22%2C%22tax_name%22%3A%22NZ+GST%22%2C%22tax_rate%22%3A%220.150000%22%7D%2C%7B%22id%22%3A%22a13a6320-2d20-11e2-8057-080027706aa2%22%2C%22product_id%22%3A%229fe945bc-2d20-11e2-8057-080027706aa2%22%2C%22min_units%22%3A%2210.00%22%2C%22price%22%3A%221.50%22%2C%22tax%22%3A%220.19%22%2C%22type%22%3A%22BASE%22%2C%22customer_group_id%22%3A%229b097e69-2d20-11e2-8057-080027706aa2%22%2C%22customer_group_name%22%3A%22All+Customers%22%2C%22tax_id%22%3A%229a025ff0-2d20-11e2-8057-080027706aa2%22%2C%22tax_name%22%3A%22NZ+GST%22%2C%22tax_rate%22%3A%220.150000%22%7D%5D%7D
Yes, it supports it out of the box.
Please, take a look on that sample: ASP.NET Web API: Sending Form-Url-Encoded Data
I have a web app written in ASP.NET MVC which usually works as it should, but upon submitting the first login page, I occasionally see the error page below. Nothing is logged in ELMAH, and a Google search has returned nothing. I've had similar results with both Chrome and Firefox. Anyone have any ideas what could be causing this?
If I click on the 'Webmaster' mailto link, the email body is filled out with the following:
CacheHost: tx22rrpep37a
ErrPage: ERR_CONNECT_FAIL
Err: (99) Cannot assign requested address
TimeStamp: Sat, 01 Dec 2012 01:52:08 GMT
ClientIP: 10.5.0.99
ServerIP: benjineering.com
HTTP Request:
POST /cloud-chm/Account/Login?ReturnUrl=%2Fcloud-chm HTTP/1.1
Host: benjineering.com
Connection: keep-alive
Content-Length: 488
Cache-Control: max-age=0
Origin: http://benjineering.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml xml,application/xml;q=0.9,/;q=0.8
Referer: http://benjineering.com/cloud-chm/Account/Login?ReturnUrl=%2fcloud-chm
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: _jsuid=782392611; ASP.NET_SessionId=i1u4twd1usymcgtppcejhsxt; __RequestVerificationToken_L2Nsb3VkLWNobQ2=F97jJ8pEE3oalgEJFpNCLMU68UE8nG2AdHeI_KDQSfiN2yOj0fV4-psVMtt59sDddJc4XdHM8DLppmdR-fen1xWHp4wkE22KwLaoCKYplWyrlBC3OmeClTcTTKXPdCTC_A-YEhEOVM6FO55fHIBCow2
This looks like a customised error page for an error at web server or infrastructure level (ie. not the application). At face value, it looks as though the your logon url cannot be found, possibly to a resource being unavailable. What type of authentication does the application use? Does it rely on another server?
Are you in control of the hosting, or do you have a 3rd party provider? If the latter you might ask them for their interpretation of the error message.
I appreciate there's no answer here, but I hope the observations and questions might help you arrive at one.
I have a REST API in Rails 3 being accessed sometimes from an AIR application and sometimes from the browser.
I think this is a Rails 3 problem but it might be a Flex/AIR problem.
The Rails app uses omniauth for authentication, cancan for authorization, and active_record_store. I use the session model to store the identity of the user.
(There is a reason I'm not using cookie sessions, having to do with AIR for Android, OAuth, and StageWebView.)
I'm using Charles to monitor HTTP traffic.
Most requests work fine. The browser (or the AIR client) sends the session ID to the server using the Cookie http header, like this:
_session_id=950dee7eca6732aa62b5f91876f66d15
And Rails finds the session, figures out who the user is, and does its thing.
But under certain circumstances, Rails generates a new session before sending the response. It adds a session to the sessions table, and returns a Set-Cookie header to the client with a new session ID. Like this:
_session_id=e1489a6b610c0a1d13cec1454228ae47; path=/; HttpOnly
The circumstances under which this happens are:
The request comes from the AIR client
The request is a POST
This is obviously a problem, because on subsequent requests, Rails can't find the user information. It created a new session without that information.
So I'm looking at the HTTP headers for the POST request. Here's a copy/paste from Charles; I inserted the colon after the header name to make it readable.
Host: localhost.seti.hg94.com:3000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/531.9 (KHTML, like Gecko) AdobeAIR/2.6
Referer: app:/AndroidApplication.swf
X-Flash-Version: 10,2,152,22
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: _session_id=950dee7eca6732aa62b5f91876f66d15
Content-Length: 84
Connection: keep-alive
Does anyone have any insight into why Rails would generate a new session under those circumstances? It seems to be happening after my controller code executes, since I have the correct session information in the controller.
I'm busy trying to isolate the problem further, control the headers from within AIR, and so on. I've been working on this bug for almost a week. So any insight or suggestions from the community would be greatly appreciated.
Only a guess, but it seems like you're not bringing across the CSRF token that Rails generates for all POST-based requests:
http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf