NEW: Log requests as curl command in log

[mdeweerd]

NEW: Log requests as curl command in log

This adds a feature to log the HTTP(s) requests as a curl command in in the log.

This allows:

• Getting all the information on a request (headers/payload/...);
• Repeating requests;
• Making better bug reports or requests for help.

[mdeweerd]

@eldy
This is currently just a "base" proposal. The functions need to be placed elsewhere and the activation needs to be conditional I think.

So awaiting for feedback on if and how you'ld like to see this be integrated, rename the functions, etc.

I proposed this in #33722 to help understand the incoming request of the API where this is most useful (generally we have control over the navigator, except when it is a remote user).

[eldy]

Let me understand.
Goal is to have in the log, a command to reproduce the command of any entered api ?

[mdeweerd]

Yes. Could also be applied to web page requests.

[JonBendtsen]

Interesting, are you also going to log the token?

[JonBendtsen]

As for the api call, could also be a mirror that reflects back what you send it?

[mdeweerd]

As for the api call, could also be a mirror that reflects back what you send it?

My opinion is that there are already mirror services available on the web.
It's an idea though (out of the scope for logging as curl).

[mdeweerd]

Interesting, are you also going to log the token?

This also logs the token as it will be part of the request.

[JonBendtsen]

Logging the token could be a security concern, I'd prefer if it was an option to log it or not

[JonBendtsen]

@mdeweerd in some debug cases I might want to log all database queries, and since all of them usually goes through
$result = $this->db->query($sql);
I could see a value in being able to log all that in perhaps a separate SQL log file. Could even be log query and another option to log results because that one is big. When logging query it is nice to know if it found anything

[mdeweerd]

@JonBendtsen I think there is already a means to log sql queries - maybe not the sql results. So logging sql results could be another useful addition to dolibarr. (However not in the scope of this proposal).

My experience with logging the HTTP requests (not specifically with Dolibarr), is that the third party is often claiming to do this or that, and the log of exact request identifies what is wrong with it.
It has also quite often allowed me to simply repeat the request and have the exact case that I could debug - enable other logging features for it, etc.

As for the HTTP request logging (for the API), I would now propose this:

• Enable logging through a variable in the config.php file;
• The value of that variable enables logging the API key or not;
• 1 enables logging without the key, 3 would enable logging with the key;
• In case the key is not to be recoreded, in case the APIKEY is present, log the head as -H "ApiKey: ${APIKEY}" - similarly for GET - so that it can just be copied and repeated with a local APIKEY in the system env.

[JonBendtsen]

@mdeweerd have in mind that permissions may not be identical

[mdeweerd]

have in mind that permissions may not be identical

Not sure what you mean, but if the developer choses not to log the APIKEY, (s)he should know that. I also suppose (or hope) that APIKEYs (can) expire.

[JonBendtsen]

have in mind that permissions may not be identical

Not sure what you mean, but if the developer choses not to log the APIKEY, (s)he should know that. I also suppose (or hope) that APIKEYs (can) expire.

APIKEYs can get regenerated, as far as I know they do not have an expire date.
Each user can only have one APIKEY and I believe that each APIKEY can only have one user.

Each user has some permissions, some can read objects, others can write and perhaps even delete.

[JonBendtsen]

Regarding permissions. If in my Dolibarr have different permissions than you do, then the results in the GUI and API may very well be different.

[JonBendtsen]

@mdeweerd i think having these curl commands would make it easier to build up a series of tests that easily can be repeated

[mdeweerd]

I think having these curl commands would make it easier to build up a series of tests that easily can be repeated

That is a good idea.
It's probably best to directly produce the PHPUNIT code I think so that one only needs to add the verification of the results.

[JonBendtsen]

I think having these curl commands would make it easier to build up a series of tests that easily can be repeated

That is a good idea. It's probably best to directly produce the PHPUNIT code I think so that one only needs to add the verification of the results.

And then I started using hurl.dev which is not really curl, but maybe the logged curl commands can automatically be transcribed to hurl.dev tests?

[mdeweerd]

@JonBendtsen
I've added an alternative to the code.

The question remains what the preferred method is to activate it (and test it, I did not test).

One method to activate it could be to add a $_GET parameter that - if present - would activate the hurl logging. (https://myserver.test/request/path?log_hurl=My%20test%20comment)

[mdeweerd]

@JonBendtsen
I updated the code to exclude the user-agent and dolapikey.

This is what the output now looks like (the option to capture the output is not enabled):

2025-10-20 10:52:40 DEBUG   127.0.0.1         26104        GET http://{{hostnport}}/api/index.php/explorer/swagger.json
Accept: application/json
HTTP 200
``

[eldy]

Closed as draft since a too long time

[mdeweerd]

@eldy I was kind of waiting for your feedback as well which I suppose is in your decision to close this PR.

[eldy]

@eldy I was kind of waiting for your feedback as well which I suppose is in your decision to close this PR.

I may have missed something.
What kind of answer did you expect ?

[mdeweerd]

@eldy
Logging permanently in htdocs/api/index.php is a 'stub' implementation - it's clearly not the final approach.

So where/when should we log as curl (when to call the function, environment variable (new or reuse), setting, based on $_GET parameter (not ok for security), etc).