I am trying to create a subscription by sending the following request:
POST https://api.fitbit.com/1/user/-/activities/apiSubscriptions/1.json
But I keep getting the following error:
Error: read ECONNRESET
Network
Request Headers
content-length: 10000000
X-Fitbit-Subscriber-Id: fitbit-subscription-handler
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJhdWQiOiIyMzk5WUQiLCJzdWIiOiI4UTJLOFYiLCJpc3MiOiJGaXRiaXQiLCJ0eXAiOiJhY2Nlc3NfdG9rZW4iLCJzY29wZXMiOiJyZWNnIHJzZXQgcm94eSBybnV0IHJwcm8gcnNsZSByY2YgcmFjdCBycmVzIHJ3ZWkgcmhyIHJ0ZW0iLCJleHAiOjE2NzU0MTgxMzYsImlhdCI6MTY3NTM4OTMzNn0.-_307-4K00hU9fdcN86G0GcONpIYMmyxr8co5dZdaHE
User-Agent: PostmanRuntime/7.30.0
Accept: */*
Cache-Control: no-cache
Postman-Token: d3f2cf54-8d4c-4d81-92e0-5cc2608b5bdb
Host: api.fitbit.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
According to Fitbit's official documentation, the content-length header is required as shown in the image:
Simply removing this required header fixes the issue.
Related
I'm using a fork of Django Simple SSO as an authentication mechanism on a Server.
It works great while we use the "standard" way to log in on the server. This means, we just access to the /login path, log in, and then navigate across the restricted paths, etc.
The problem comes when we want to connect to a 3rd server that also relays on SSO auth vía javascript/AJAX without direct access to /login path first.
I've tried to use django-cors-headers but didn't get the expected result.
I'm close to give up so any help is welcome.
The problem
Assume we are logged in on server 1 and auth server and we want a resource on server 2
When the browser is redirected to the Auth Server in order to verify that the browser is logged with a valid user, the cookie header is not transferred.
(See the diagram on button for further details on how Django Simple SSO works)
The headers set by the auth-server on the preflight request are the following:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: accept-encoding, accept, authorization, cookie, content-type, dnt, origin, user-agent, x-csrftoken, x-grafana-org-id, x-dashboard-id, x-panel-id, x-requested-with
Access-Control-Allow-Methods: DELETE, GET, OPTIONS, PATCH, POST, PUT
Access-Control-Allow-Origin: https://server1-domain
Access-Control-Max-Age: 86400
Connection: keep-alive
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 16 Jul 2021 12:14:54 GMT
Server: nginx
Vary: Origin
The headers on the GET request where the following:
Request/Client:
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: es-ES,es;q=0.9,en-US;q=0.8,en;q=0.7
Connection: keep-alive
Host: auth-server-domain
Origin: https://server1-domain
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36
x-grafana-org-id: 1
Response/Auth Server:
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://server1-domain
Connection: keep-alive
Content-Language: es
Content-Length: 0
Content-Type: text/html; charset=utf-8
Date: Fri, 16 Jul 2021 12:14:54 GMT
Location: /error_unauthorized_page
Referrer-Policy: same-origin
Server: nginx
Vary: Accept-Language, Cookie, Origin
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
I think all the headers are correct, but it's clearly there are some error.
On the cookie side, I have tried to play with the SingleSite property, setting it to None and Lax without any change.
The domain set on the cookie browser's memory is "correct" from my point of view as it is .auth-server-domain (note the dot).
I'm using DJango 3.2.5 and Google Chrome as a web browser.
If you have any idea of why cookie is not being send on the auth-server-domain cors requests, I will really appreciate your comments.
If do you think I have missed any piece of relevant information, feel free to ask!
Thank everyone to reach this point and help me!
Appendix:
A simplified schema of how Simple SSO works:
I've seen the API for this which suggests adding the Reply-To header or h:Reply-To param. I don't have any experience with headers so that may be why I'm having trouble with this.
I'm trying to construct the request in postman, and I've tried putting Reply-To as a header key and an email as the value, and I've also tried without that header and instead with a param with the key h:Reply-To but when I hit "reply" to the email that gets sent, it always replies to the sender instead of my reply-to address.
Can anyone help me?
as header
POST /v3/sandboxXXXXba.mailgun.org/messages?from=messages#xxxx.com& to=xxxx1#gmail.com& subject=hello& text=mailgun-test HTTP/1.1
Host: api.mailgun.net
Reply-To: xxxx2#gmail.com
Authorization: Basic xxxx
cache-control: no-cache
Postman-Token: xxxxx
as param
POST https://api.mailgun.net/v3/sandboxXXXX.mailgun.org/messages?from=messages#domain.com&to=me#gmail.com&subject=hello&text=mailgun-test&h:Reply-To=me#gmail.com
aka:
POST /v3/sandboxXXXXX33ba.mailgun.org/messages?from=messages#mydomain.com& to=myaddress#gmail.com& subject=hello& text=mailgun-test& h:Reply-To=myaddress#gmail.com HTTP/1.1
Host: api.mailgun.net
Authorization: Basic xxxxx
User-Agent: PostmanRuntime/7.15.2
Accept: */*
Cache-Control: no-cache
Postman-Token: xxxx
Host: api.mailgun.net
Accept-Encoding: gzip, deflate
Content-Length:
Connection: keep-alive
cache-control: no-cache
So it should be a form-data body parameter:
POST /v3/skedda.co/messages HTTP/1.1
Host: api.mailgun.net
Authorization: Basic YX...
User-Agent: PostmanRuntime/7.15.2
Accept: */*
Cache-Control: no-cache
Postman-Token: ...
Host: api.mailgun.net
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 781
Connection: keep-alive
cache-control: no-cache
Content-Disposition: form-data; name="from"
postmaster#...com
------WebKitFormBoundary7MA4YWxkTrZu0gW--,
Content-Disposition: form-data; name="to"
a....com
------WebKitFormBoundary7MA4YWxkTrZu0gW--,
Content-Disposition: form-data; name="subject"
link test
------WebKitFormBoundary7MA4YWxkTrZu0gW--,
Content-Disposition: form-data; name="html"
<h1>Hello world</h1>
------WebKitFormBoundary7MA4YWxkTrZu0gW--,
Content-Disposition: form-data; name="h:Reply-To"
notifications#...com
------WebKitFormBoundary7MA4YWxkTrZu0gW--
or in Postman itself
It's a CORS problem again
[and I don't have much knowledge about CORS].
My environment :
I have JSON file stored in Amazon S3 server, and reading this JSON file from my web application.
My issue :
I am getting this in FireFox only
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at server. (Reason: CORS header
‘Access-Control-Allow-Origin’ missing)
Note : I have configured CORSRule in the server [Amazon S3]; after that, Chrome and other browsers work properly, but Firefox gives this error.
In Firefox Network tab [inspect element]:
Status : 403
Method : OPTIONS
Cause : xhr
Type : xml
Request Headers :
Host: myWebApp.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/plain, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
X-Requested-With: XMLHttpRequest
Referer: https://myWebApp.net/page.jsp
Connection: keep-alive
Response Headers :
Content-Length: 0
Date: Thu, 24 Nov 2016 07:27:30 GMT
Location: https://webApp.s3.amazonaws.com/file.json
Server: Apache-Coyote/1.1
I have looked around but didn't find any causes.
So I need your help.
As it works properly in the Chrome browser, the issue is in Firefox only.
Please describe step by step if possible [I am new to these things].
Opps!
Finally got solution.
The issue was in Amazon S3's CORSConfiguration
I don't know much about it, but now its allowing Cross-Origin from all browsers.
I have changes CORSConfiguration as :
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>https://myWebApp.net</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>POST</AllowedMethod>
<AllowedMethod>PUT</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<MaxAgeSeconds>3000</MaxAgeSeconds>
<ExposeHeader>x-amz-server-side-encryption</ExposeHeader>
<ExposeHeader>x-amz-request-id</ExposeHeader>
<ExposeHeader>x-amz-id-2</ExposeHeader>
</CORSRule>
</CORSConfiguration>
by this rules, browsers getting proper Request Headers and Response Headers.
Request Headers :
Host: myWebApp.s3.amazonaws.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-requested-with
origin: https://myWebApp.net
Connection: keep-alive
Cache-Control: max-age=0
Response Headers :
Access-Control-Allow-Headers: x-requested-with
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Origin: https://myWebApp.net
Access-Control-Max-Age: 3000
Content-Length: 0
Date: Thu, 24 Nov 2016 13:21:17 GMT
Server: AmazonS3
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
access-control-allow-credentials: true
access-control-expose-headers: x-amz-server-side-encryption, x-amz-request-id, x-amz-id-2
x-amz-id-2: emYYMILNIdkCejpjuDXz4Haks87asdhj/7JL5AASt/8eIwKdgO1Gb/AzGRg7SU/GH55IVopScg=
x-amz-request-id: 307572CDFF39F443
I have a web service that requires basic authorisation and a user behind an internet proxy that requires NTLM authorisation. I also have a forms application that makes calls to the web service and also asks the user for the web service credentials (which are different from the NTLM credentials).
I got the app configuration working (WCF ServiceModel), it's using the default proxy credentials, the request is authenticating with the proxy, but after it authenticates with the web service it does not send the request body for some reason.
The process works if I test locally without the NTLM proxy. Sorry about the long examples, but I had to include them.
1st request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM
Proxy-Authenticate: BASIC realm="corporaterealm"
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: close
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: close
Content-Length: 1057
Proxy-Support: Session-Based-Authentication
[...]
2nd request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0
Receive:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM TlRMTVNTUAACAAAAEAAQADgAAAAFgomiysOwieqrhFEAAAAAAAAAALIAsgBIAAAABQLODgAAAA9DAE8ATQBFAFQATgBFAFQAAgAQAEMATwBNAEUAVABOAEUAVAABABoAVgBJAC0AUgBJAEMASwBEAEMALQAwADAAMQAEABwAYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAMAOABWAEkALQBSAEkAQwBLAEQAQwAtADAAMAAxAC4AYwBvAG0AZQB0AG4AZQB0AC4AbABvAGMAYQBsAAUAHABjAG8AbQBlAHQAbgBlAHQALgBsAG8AYwBhAGwAAAAAAA==
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Proxy-Connection: Keep-Alive
Set-Cookie: BCSI-CS-36204A5A7BBD24D9=2; Path=/
Connection: Keep-Alive
Content-Length: 1074
Proxy-Support: Session-Based-Authentication
[...]
3rd request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate
Proxy-Authorization: NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAABAAEABIAAAADgAOAFgAAAASABIAZgAAAAAAAACoAAAABYKIogUBKAoAAAAPQwBPAE0ARQBUAE4ARQBUAFAAYQByAHMAbwBuAEoAVwBTAFIASwAwADQAOAA3ADAAlap7g+mPRMEAAAAAAAAAAAAAAAAAAAAARLAhi5lf3nd+l9xENAcu2W6xf6iJbyM6
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:09:33 GMT
Cache-Control: proxy-revalidate
Content-Length: 1656
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Proxy-support: Session-based-authentication
Age: 0
[...]
4th request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate,gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIoggACAAxAAAACQAJACgAAAAFASgKAAAAD1dTUkswNDg3MENPTUVUTkVU
Host: www.myservice.com
Content-Length: 0
Receive:
HTTP/1.1 400 Bad Request
Date: Tue, 31 May 2011 13:09:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, proxy-revalidate
Content-Length: 0
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Age: 0
I don't understand why it doesn't send the envelope in the 4th request. The two handshakes are done, so theoretically everything should be fine.
When I do this locally without the NTLM proxy, the envelope gets sent as expected:
1st request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="myrealm"
X-Powered-By: ASP.NET
Date: Tue, 31 May 2011 13:31:46 GMT
[...]
2nd request:
Send:
POST http://www.myservice.com/service.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://tempuri.org/MyMethod"
Accept-Encoding: gzip, deflate,gzip, deflate
Authorization: Basic Y29nZW50YVxjb21ldC1kbTM6Kmh0JTg2NCU=
Host: www.myservice.com
Content-Length: 329
Expect: 100-continue
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>[...]</s:Body></s:Envelope>
Receive:
HTTP/1.1 200 OK
Date: Tue, 31 May 2011 13:31:47 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Set-Cookie: ASP.NET_SessionId=svv4i11awg05v1j5viz1impo; path=/; HttpOnly
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 5127
[...]
I had to change the server security configuration to accept Digest authentication. For some reason that works while Basic doesn't.
I encountered a potentially similar issue and believe in my case this may be related to the establishment of the original NTLM connection to the proxy.
In my experience I had three requests going out in sequence each hour, with a retry configured.
Of these requests two would work, one would fail with a 400, and then when the first retried it worked as well.
There is a similiar issue with IE identified here: http://blogs.msdn.com/b/asiatech/archive/2012/01/30/400-bad-request-when-posting-webservice-or-wcf-request-from-ie.aspx
I ran some network traces and watched the behaviour and noticed that often the TCP Streams seemed to get shared, so that one of the requests would end up sending an NTLM authentication message (the zero content length) to the proxy after the other had already authenticated. In this situation the proxy just passed through the zero content message (as the stream had already authenticated).
What fixed it for me was moving to a WCF-Custom customBinding (using textMessageEncoding with a messageVersion of Soap11 to maintain my basicHttpBinding behaviour) and (not sure if required) setting keepAliveEnabled to false.
Unfortunately I doubt this is much help for your particular situation, but more info never hurts.
Hi quick question about Jayrock... I have a Jayrock JSON-RPC web service that generally works fine. However, when I try to post to my jqGrid editUrl, Jayrock throws an error. The web service works fine in other situations.
Anyone have a clue why Jayrock doesn't like the following request? Perhaps a way to configure Jayrock to accept this request?
Request:
POST
/StoryManager/StoryManager.ashx/setPageItemRoles
HTTP/1.1
Host: localhost:2064
User-Agent: Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.9.1)
Gecko/20090624 Firefox/3.5 (.NET CLR
3.5.30729)
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset:
ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Content-Type:
application/x-www-form-urlencoded;
charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer:
http://localhost:2064/StoryManager/PageItemDetail.aspx
Content-Length: 183
Cookie:
ASP.NET_SessionId=uycy1qmowzzqhiac1kg3e455
Pragma: no-cache
Cache-Control: no-cache
title=Narrative&assignedto=dfghdfgh&assigned=2009-06-25T14%3A52%3A24.0868931-05%3A00&due=2009-08-02T14%3A52%3A24.0868931-05%3A00&completed=2009-07-17T14%3A52%3A24.0868931-05%3A00&id=3
Response:
{"id":null,"error":{"name":"JSONRPCError","message":"Found
String where Object was
expected.","stackTrace":" at
Jayrock.Json.JsonReader.ReadToken(JsonTokenClass
token) in
c:\Projects\Public\Jayrock\rel\rel-0.9.8316\src\Jayrock.Json\Json\JsonReader.cs:line
142\r\n at
Jayrock.JsonRpc.JsonRpcDispatcher.ParseRequest(TextReader
input) in
c:\Projects\Public\Jayrock\rel\rel-0.9.8316\src\Jayrock\JsonRpc\JsonRpcDispatcher.cs:line
271\r\n at
Jayrock.JsonRpc.JsonRpcDispatcher.Process(TextReader
input, TextWriter output) in
c:\Projects\Public\Jayrock\rel\rel-0.9.8316\src\Jayrock\JsonRpc\JsonRpcDispatcher.cs:line
127","errors":[{"name":"JsonException","message":"Found
String where Object was expected."}]}}
Because you send application/x-www-form-urlencoded request with "form-like" post data instead of application/json with correct json object.