I was looking for a rfc or some other standard to find out the HMAC signature of a HTTP Request, specially to POST/PUT where body is not empty, I only have found the generic RFC (http://www.ietf.org/rfc/rfc2104.txt) but not specifying the case of an HTTP.
We had a look to how other (AWS, Facebook, Twitter) have done it, but each of them have their own solutions, does anybody know the more official standard for that?
Thanks in advance
Related
I'm building a ReactJS frontend that has to gather some data from AWS Lambdas using a JS fetch.
I cannot make it work, no mater what CORS technique I apply. I've looked into other answers here to no avail.
I am definitely adding Access-Control-Allow-Origin with "*" value in my response (verified this using postman to call the endpoint). Also, Chrome complains about the preflight with Response to preflight request doesn't pass access control check, but no preflight request (OPTIONS method) is ever actually fired by chrome, all I see is the GET I'm trying to make on the first place, which is really confusing.
What am I missing? Why is chrome complaining about preflight when no OPTIONS preflight request is made? Why adding Access-Control-Allow-Origin with "*" in my response is not enough?
Thanks!
TL;DR: There was a preflight request happening, it just wasn't showing on chrome (there's a way to make them show up). Also, there's a tweak to make if you use custom headers for authorization tokens for example.
Summary
Well, after looking into this for a day and checking several other answers I'm posting this because none quite fit my problem, with the hope it will help anyone else facing this.
First, I'll summarize the several parts involved in the error and then how to fix it, without resorting to any "hackish" solution like bypassing CORS with a chrome extension, or using any 3rd party service, like many posts suggest. My setup looked like this:
ReactJS frontend, try to make a GET request using fetch javascript method, running on http://localhost:3000 for development
AWS Lambda Backend, that answers the GET with a JSON payload (coded in python, not important but anyways). This lambda is adding Access-Control-Allow-Origin:"*" header to its response.
The above AWS Lambda is behind what AWS calls an "Authorizer", which is a function that runs before your lambda to check whatever authorization header you want to use to protect access to your API. This is important as we'll see later, because due to some nonsense on AWS inner workings, sometimes you cannot use the standard HTTP Authorization header, and it defaults to using authorizationToken as they suggest in their documentation and samples (and changing it not always works, there are plenty of users reporting this in their forums). We'll keep a note on this for later.
Both API methods (actual API and its Authorizer) routed and published on the internet using AWS API Gateway, which in short is a way to pair your lambda with a public URL to call it from elsewhere.
Google Chrome used as browser (with its developer tools enabled to monitor things)
The error
When trying to call the lambda, chrome blocks the GET request with this error showing on the console: Response to preflight request doesn't pass access control check. My lambda is already answering with the correct Access-Control-Allow-Origin header so, what's wrong? Also, no preflight OPTIONS request are being made anyways, so this was confusing.
Some debugging
AWS Lambda is great but their debugging tools are not as fluid as I would like, so I replaced the lambda with a local expressjs server, implementing just two methods: GET /foo and OPTIONS /foo. To my surprise, when from my ReactJS frontend I fetched /foo, it did call OPTIONS /foo first (I confirmed this by adding logs to my endpoint, etc, something you can also do in lambdas but its not as easy).
What was actually happening
A "preflight" request is an OPTIONS request to validate what is actually allowed when doing the following GET, but the Network tab in Chrome was not showing any OPTIONS request actually happening (I remember they used to show up here). Well, they changed it at some point, and now they are hidden by default. If you want them to show again (as a developer, I do), you can re-enable that by changing the out-of-blink-cors flag to disabled as explained here.
After changing this flag, now the OPTIONS request does show on the network tab. From there I could craft the OPTIONS response so it would enable the required GET afterwards. There are other considerations when using credentials and other cases (I found this article from Mozilla helpful with that), but in short my OPTIONS response headers look like this:
Access-Control-Allow-Origin: "http://localhost:3000"
Access-Control-Allow-Methods: "GET, POST, OPTIONS"
Access-Control-Allow-Headers: "authorizationToken"
(That last one, Access-Control-Allow-Headers, comes into play when dealing with AWS Lambdas Authorizers. If you are using that custom header to send your tokens, you need to allow it here).
After making CORS work locally, to solve it for my lambdas I did two things:
You need your API Gateway to be able to answer OPTIONS request. There are a number of ways to achieve this, from writing your own lambda to answer it to having AWS to mock-response it for you. More info on that here.
You need to make sure your GET lambda adds the Access-Control-Allow-Origin header, pointing to the same value your OPTIONS response did (In my case, http://localhost:3000).
After that, all worked as expected.
Final Notes
I wrote this answer because I found the conjunction of "React-CORS-AWS-Authorization" was not actually covered by any questions I found around.
Also there are a number of problems that may arise from using localhost for development on chrome, leading to suggestions of using an external service like lvh.me, but this was not the case, and some answers misleadingly relate this CORS problem to that. Moreover, some answers suggest disabling CORS checks altogether with some chrome extension, which is really bad security advice.
Finally, I found the idea of making a simple expressJS server to debug the server-side of things pretty helpful in understanding what was happening, because sometimes you simply cannot access what's happening on the other side, so maybe this suggestion might help people shorten the time dealing with things like this.
I'm using a 32-bit microcontroller (program code written in C) with very limited flash space that is communicating with a cellular module. I have an Azure account setup with an IoT Hub and I would like to send some device-to-cloud messages to my IoT Hub. I have tested and confirmed both HTTP and HTTPS communication to other servers. However, I can't find anywhere that specifies what the required HTTP headers are for sending a device-to-cloud message. Can anyone provide a description of the required HTTP message format (the HTTP start line, required HTTP headers and the HTTP header values)?
I found the Azure SDK for C, but even with all the optimization options turned on it takes up too much codespace for my microcontroller. I've tried following the code in the SDK for how the HTTP message is built, but I seem to be missing some pieces. I only have two or three device-to-cloud messages that I am sending, so I assume that if I know what the headers are it won't take much code to generate the device-to-cloud messages.
The cellular module I have is handling the X.509 certificates for mutual TLS authentication. Assume that is working. For this question I'm only concerned with finding the required HTTP message formatting for a Azure IoT device-to-cloud message.
EDIT:
Following a suggestion from a comment, I was eventually led to this page:
https://learn.microsoft.com/en-us/rest/api/iothub/device/senddeviceevent
Using the suggested HTTP POST (with my device specifics replaced), I am now getting a 401 error (IotHubUnauthorizedAccess). I thought I understood how the authentication was supposed to work, but I guess I was wrong.
My IoT device has a symmetric key. I thought I was supposed to include a header formatted as:
Authorization:SharedAccessKey=<my_primary_key>
but that doesn't work. My HTTP body is simply:
{"deviceID":<my_IoT_Device_ID>}
Where am I supposed to include the symmetric key information, and what is its format?
After some trial and error, we found out it's much easier than we thought. If you are using X.509 certificates for client authentication, you don't need to include anything in the HTTP message content to specify your authentication. The minimum required for an Azure device-to-cloud message using X.509 certificates for authentication is:
POST /devices/<id>/messages/events?api-version=2018-06-30 HTTP/1.1
Host:<fully-qualified-iothubname>.azure-devices.net
Content-Length:<number-of-bytes-in-the-JSON-body>
{"deviceID":"<id>",<your-JSON-formatted-custom-d2c-message-data>}
where <id> is the device ID as listed on the Azure IoT Hub and <fully-qualified-iothubname> is the IoT Hub name. I believe Azure supports chunked encoding if you want to do that instead of using the Content-Length header.
While integrating FreshDesk in my product,I am stuck with Create Ticket with attachment API. I am using Advanced Rest Client for testing APIs.I have seen many forums and questions on the Stack Overflow itself but I am still not satisfied with any answer pertaining to multipart-form-data POST request for uploading files.
I would like to know the Request Format required in Advanced Rest Client along with headers.
As of now, this is the request I am using but I am not getting a proper response:
-----------------------------7d01ecf406a6
Content-Disposition: form-data;name="files";filename="text1.txt"
Content-Type:text/plain
Its a nice day.
-----------------------------7d01ecf406a6--
I just spent the last hour on this same issue, thinking I was doing something wrong. I eventually gave up on ARC and tried PostMan and set all the values the same and it worked on the server-side (I'm using node.js+hapi) where previously the server was returning 415 with little more info (there's an open issue in Hapi regarding this).
After seeing the requests at the server when using PostMan and considering the UI feedback ARC regarding multi-part (implying it would overwrite any included content-type headers), I've concluded that it's supposed to overwrite/include the content-type header AND provided the boundary, but is not and so my requests were failing.
I've also looked at closed and open issues for ARC ( https://github.com/jarrodek/ChromeRestClient/issues?utf8=%E2%9C%93&q=is%3Aissue%20multipart ) and it looks a lot like there are known issues with multi-part uploads from the client so I'd suggest you not spend too much more time with ARC until you've tried another client to eliminate ARC as the source of your issues.
You need to set proper Content-Type header
Content-Type: multipart/form-data; boundary=---------------------------7d01ecf406a6
Server needs to know what to look for in the request body. In case of multipart/form-data you need to pass the boundary you have used in the Content-Type header.
This route works, and works nicely using SoapUI:
from("restlet:http://localhost:8484/restletTestService/submit?restletMethod=POST")
.routeId("myRestletSubmitRoute")
.unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
.to("bean:myServiceSubmitProcessor")
.marshal().json(JsonLibrary.Jackson, MyResponse.class);
Using SoapUI, I can post jsons that conform to the structure of the MyRequest class and I get a json back with the info I think I should.
However, when I created a quick angularjs page to allow users to build a request on the fly and then 'POST' to my rest endpoint, well:
XMLHttpRequest cannot load http://localhost:8484/restletAddressService/addressPersonator/submit. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access. The response had HTTP status code 405.
I'm pretty sure that I have to somehow set the header Access-Control-Allow-Origin to some value on the restlet URI, but I haven't a clue how to do that. I researched the documentation (http://camel.apache.org/restlet.html) and googled it, but I'm not finding anything that has helped.
Does anyone know the answer? Thanks!
UPDATE
So the answer from fiw gave me the hint I needed along with some google research on HOW a call to a rest resource determines what's allowed (plus quite a bit of good-ole-fashioned trial and error :) ). This is what wound up working:
from("restlet:http://localhost:8484/restletTestService/submit?restletMethod=POST")
.routeId("myRestletSubmitRoutePOST")
.unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
.to("bean:myServiceSubmitProcessor")
.marshal().json(JsonLibrary.Jackson, MyResponse.class)
.setHeader("Access-Control-Allow-Headers", constant("Content-Type"))
.setHeader("Access-Control-Allow-Origin", constant("*"));
from("restlet:http://localhost:8484/restletTestService/submit?restletMethod=OPTIONS")
.routeId("myRestletSubmitRouteOPTIONS")
.setHeader("Access-Control-Allow-Headers", constant("Content-Type"))
.setHeader("Access-Control-Allow-Origin", constant("*"));
Thanks!
I think you need to set Access-Control-Allow-Origin as a header on the response with a value of * as you've suggested. So to do this in camel:
from("restlet:http://localhost:8484/restletTestService/submit?restletMethod=POST")
.routeId("myRestletSubmitRoute")
.unmarshal().json(JsonLibrary.Jackson, MyRequest.class)
.to("bean:myServiceSubmitProcessor")
.marshal().json(JsonLibrary.Jackson, MyResponse.class)
.setHeader("Access-Control-Allow-Origin", constant("*"));
This came from reading: enable cors on your server.
I would like to know if it is possible to add a short cookie in the http header of a request that would not be erased over the session.
It would be nice to prevent a loadbalancer to do ssl termination but just reading th cookie and do the logic accordingly.
-> This is for theoretical purposes only
Digging into all the rfc is a huge undertaking so if someone knows.. That would be nice :)
Thanks