Quick question: is it necessary to define a new header action-location for auditing requests? The reason I ask is that this adds some kind of burdeon to any client calling up to WebAPI that they need to set a header for proper audit (If I am understanding the function correctly). Doesn't that mean that we have to 'trust the client' that they are setting this header? Or could something be set by the header that is potentially compromising? So my queston boils down to: can auditing in WebAPI be performed independently of any client-submitted information (other than the requested resource, of course).

@chrisknoll
action-location header is not necessary. Without it, log just will not contain the page URL. So yes - auditing in WebAPI can be performed independently of any client-side application (Atlas or any other).

Ok, thanks for clarification. I didn't understand that the third bullet wasn't about rest calls from atlas to webapi would be logged, it was about a rest call to log the SPA navigation around Atlas.

Please do not take the default commit message from the squashed commit, this is what was put into the commit message:

* [Geospatial] Map or geospatial tab should not be shown for "non-geo" data sources #2412

* [Geospatial] Map or geospatial tab should not be shown for "non-geo" data sources #2412

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation

* Audit trail implementation - sessionId

* Audit trail implementation - sessionId

* Audit trail implementation

* Audit trail - exclude another versions of log4j

* Audit trail implementation

* Audit Trail - expired token fix

* Audit Trail - disabled by default

This is not useful since many of the commit messages are just duplicates and don't describe the actual change in the commit.

This is very important: we want commit messages to contain information that is useful to a deveoper to understand the purpose of the commit. What feature was added? Did new dependencies get added? What issue does this close? Any given PR should be able to provide a short summary of changes. Please make an effort to have clean commit messages.