I was stressful whenever my teammates, talented developers, share the curl, which including the secret credentials like - Authorization Token, for detecting and resolving the issues. So, I am curious that how you guys do that ? There have any better way to send an API bug report ?
Updated:
--
I think that way is not secure enough. For example, I can use Secret Token, which is exposed in curl, to do something like ~ buying my own stuff .
So, there have anyway to secure the curl ? But we are still easy to detect the API issue.
Sorry, maybe I don't say clearly enough :(. Let show some code, hope it easy to understand.
I found that, the order listing API doesn't work as expected. I send the curl to my teammate. Please take a look at `-H 'X-Access-Token: SECRET_TOKEN' \`
1/ If I don't replace the real token by SECRET_TOKEN, others can use it to buying their own stuffs, by my token. :(
2/ If I replace the real token by SECRET_TOKEN, it's so hard to detect what the problem is, cause my teammate can't see the response, and can't request to re-produce the issue too.
1/ We should have an API tracing system, hosted in a server for example, which capture all requests, including the params, headers, response. with some secure rule, e.g. hide Secret-Token header.
2/ Each request will have a header, its value is the request-id for example
3/ Whenever a bug come, we just need use request-id from 2/ and search the information in 1/
I built several tracing systems, but none of them capturing & storing the API's response, cause too expensive, you know. Could you share more about your tracing system? I think we can learn from others.
It makes sense. I think one of the challenges is the question of how much you need to store in order to be able to do this. Hanging onto every request/response object / parameters for an interaction with an API can be become expensive pretty quickly.
This becomes an issue when you start thinking about what is considered to be a bug. If you're just talking about error codes, then you're probably fine to store everything. But when you talk about unexplained (but not erroneous) behaviour from the API, how much you need to store to catch the bugs is an important consideration.
18 comments
[ 2.7 ms ] story [ 52.3 ms ] threadUpdated:
--
I think that way is not secure enough. For example, I can use Secret Token, which is exposed in curl, to do something like ~ buying my own stuff .
So, there have anyway to secure the curl ? But we are still easy to detect the API issue.
If you don't like curl, think maybe you're more of a postman person?
So, there have anyway to secure the curl ? But we are still easy to detect the API issue.
I found that, the order listing API doesn't work as expected. I send the curl to my teammate. Please take a look at `-H 'X-Access-Token: SECRET_TOKEN' \`
```
curl 'https://mocha.lozi.vn/v6/users/me/orders' \ -X GET \ -H 'X-Access-Token: SECRET_TOKEN' \ -H 'Host: mocha.lozi.vn' \ -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:101.0) Gecko/20100101 Firefox/101.0' \ -H 'Accept: /' \ -H 'Accept-Language: vi_VN' \ -H 'Accept-Encoding: gzip, deflate, br' \ -H 'X-Lozi-Client: 1' \ -H 'X-City-ID: 50' \ -H 'Origin: https://loship.vn' \ -H 'Connection: keep-alive' \ -H 'Referer: https://loship.vn/' \ -H 'Sec-Fetch-Dest: empty' \ -H 'Sec-Fetch-Mode: cors' \ -H 'Sec-Fetch-Site: cross-site'
```
The problem is:
1/ If I don't replace the real token by SECRET_TOKEN, others can use it to buying their own stuffs, by my token. :(
2/ If I replace the real token by SECRET_TOKEN, it's so hard to detect what the problem is, cause my teammate can't see the response, and can't request to re-produce the issue too.
1/ We should have an API tracing system, hosted in a server for example, which capture all requests, including the params, headers, response. with some secure rule, e.g. hide Secret-Token header.
2/ Each request will have a header, its value is the request-id for example
3/ Whenever a bug come, we just need use request-id from 2/ and search the information in 1/
Right ?
1/ secured, the credentials should not be exposed.
2/ enough information, e.g. the response must be snapshot, general parameters should be transparent.
3/ easy to re-produce and confirm resolved.
What do you think?
This becomes an issue when you start thinking about what is considered to be a bug. If you're just talking about error codes, then you're probably fine to store everything. But when you talk about unexplained (but not erroneous) behaviour from the API, how much you need to store to catch the bugs is an important consideration.