Allow to view/change logger levels through the API

[yangyongzhi7]

When I used the zaproxy to scan some applications, I want to know which logger level does zaproxy use.

So I want to implement a api to view the logger level , it;s url maybe like this:
http://zap/JSON/core/view/loggerlevel/?zapapiformat=JSON&apikey=111&formMethod=GET
and response will be like this:
{"loggerlevel":"DEBUG"}

Or some other suggestions?

[psiinon]

ZAP uses log4j, so the logger level can be set on a per class basis.
But it would be good to be able to get and set the logger levels via the API (and UI for that matter)

[yangyongzhi7]

Thank you first.
I mean that I want to know which level the log4j.propertis is using.
Because sometime If you set it as DEBUG, the zaproxy is running slow perhaps there will be too many IO operations, in order to see this level on web UI conveniently, I think I need a api to get the logger level setting.

[psiinon]

Yeah, I understood. But theres not actually just one level, there can be a different level per class. If we add API calls for this we should cope with the general case.

[kingthorin]

#4513 (comment)

[kingthorin]

Would we want a UI for this as well or just API calls and scripts?

(I'm asking because I don't want to implement API actions and then find out we should have named them differently if they're options in the UI.)

I personally don't think it's necessary to have in the UI, given it can be handled simply with a standalone script and the majority of users shouldn't need to change it.

I guess if we add a UI in the future it could also be a dialog or different type of panel in the UI.

[psiinon]

I dont think we need a UI right now. It could be a panel in the Options, but def not a priority for me.

[kingthorin]

So I've currently added views loggingSummary (which is limited to the top level paros and zap packages, similar to what was done for the CLI stuff) and loggingDetails (which loops through all loggers and spits out a map/table, optionally filtered by a package name [starts with]).

Shall I add an action with a generic name like setLoggingDetails that accepts a package/classname and lets the user set a level?

[thc202]

IMO setLogLevel (to match the command line arg) with name and level as parameters.

[kingthorin]

Shall I rename loggingSummary to getLogLevel then? Suggestions for the detailed view, maybe getDetailedLogLevel?

For consistency.