I’m testing various HTTP methods using curl from the command-line, and I’m observing that clients are not properly authenticated for various methods. The expected behavior is that the user must include -u "PROJECT_ID:PROJECT_SECRET" in the command, in order for it to be accepted.
For methods like pin_rm, this is the case: if you do not include these credentials, a 403 Forbidden response is returned, as expected. However, for methods like pin_add and cat, 200 OK and data are returned, regardless of whether the credentials are passed. (I tried each method both with and without credentials to check this.)
Perhaps I’m missing something, but I’m concerned about third parties invoking my dedicated gateway and bypassing secret key authentication. Please see if you can reproduce this behavior and confirm what we should expect. Thank you in advance!
@Gray_Newfield this behavior is expected, it is not a bug.
We do rate-limit users who do not use authentication on write and read requests, but this is still possible to do. Please refer to the following:
@lovekosmas I see now, thank you for clarifying. A couple of follow-up questions:
-
Does the server response indicate if the authentication was successful, other than the status code? I’m presently receiving 200s, but I have only light testing traffic, so I have not come close to the anonymous throttling limit.
-
If I do start getting throttled what should I expect to see? 403 status code? Do all throttled requests receive the same response, regardless of whether they are authenticated or anonymous?
-
Server response does not indicate if the authentication was successful or not, you will receive 200 in case you use it correctly, if not you will receive an appropriate error message about what went wrong.
-
The only response you will get is 429 in both cases with authentication or without.
It is a matter of how soon you will get a rate-limited error is a difference between the two.
The difference in the speed is significant as an example below states if your will go above you will get 429 responses:
For the write requests
Without authentication - 12 requests/minute limit
With authentication - 10 requests/second limit
Let me know if you have any further questions, @Gray_Newfield!
Hey everyone, just wanted to share the solution I used in order to achieve the desired behavior of blocking all unauthenticated requests.
For context, I am calling my IPFS dedicated gateway from inside an AWS Lambda function. I use Axios to send the request, which includes the authentication header (project ID + secret key). As mentioned above, this authentication permits you a higher rate limit, but it still allows unauthenticated requests at a lower rate.
In order to block all unauthenticated requests and only allow authenticated ones, I added the Origin header to my request and let the value contain my credentials ("PROJECT_ID:PROJECT_SECRET"). I then set this same value in the HTTP Origin section of my project security settings. The result is that my gateway will now block any requests that do not have this header and value, responding with 403 Forbidden.
Note that the key to making this work is sending the request from the backend, instead of from the client-side. Browsers automatically set the Origin header for you, but when doing so from Lambda, I was able to set it to whatever value I want. Also, by doing this on the backend, I am able to avoid exposing my credentials, which would have happened from the client side. For more details on my decision to use Lambda in order to keep my credentials private, check out this earlier post.
4 Likes