Auditing @@sharing changes?

Is there an add-on to log and audit any changes done through the @@sharing view?

The implementation in plone.app.workflow already emits a LocalrolesModifiedEvent with all the form data however I just need the diff between old and new state...is there anything existing?

-aj

Hi Andreas, check out collective.auditlog: https://pypi.python.org/pypi/collective.auditlog

there is also collective.fingerpointing; it currently doesn't support that event but it should be easily implemented.

None of these tools deals with the @@sharing implementation and the modification of local roles.

-aj

you can write a new subscriber for this event and use it for the audit log; here's an example for doing that as currently implemented for registry changes:

Please read again:

This information is not available from the event and it is not computed in the hande_form() implementation of the SharingView class.

-aj

That's a shame, and ought to be fixed in the sharing view.

AFAICT, that event already does something strange by passing the request as the first descriptions object; with that precedent set, I would think it reasonable to capture the state of __ac_local_roles__ before modification, and pass that previous state another argument to the event's constructor? That would be a minimal change and allow the subscriber to implement the diff however it wants downstream of core?

Sean

1 Like

I currently hacking a monkey-patch for handle_form() that will determine the old state and do the diffing of roles and user ids involved. I think it should not be big deal to attach the re-computed settings variable and the structure representing the diff between old and new state to the event. In our case are not using something like collective.fingerpointing or collective.auditlog but my more generic zopyx.plone.persistentlogger for having the logging persistent on each content object (by-design).

-aj

Here is my current implementation that collects all incremental changes in a diff_context

which will contain something like

{'added_userids': set([]),
 'block_localroles': False,
 'removed_userids': set([]),
 'role_changes': {'3c8313bb-7e5b-40c1-9eed-6785a9bc7eef': {'added': set([u'Reviewer']),
                                                           'removed': set([])},
                  'eudat-admin': {'added': set([]),
                                  'removed': set([u'Editor'])}}}

After reviewing the state of the other modules:

  • collective.fingerpointing is a good start how it uses an external logfile..not very useful with multiple app-servers generating different audit logs, hard to filter, hard to store supplementary information like the dict structure above
  • collective.auditlog implementing some supplementary functionality compared to fingerpoint...using an external database...more moving targets.

Our approach is to store all audit information as annotation on the related context objects with the opportunity to filter logging entries, display nicely formatted internal data etc. OK..storing auditing information inside the ZODB will grow your database size however this works for us in several small and med-size installations without issues. If you

@zopyx if you are going to store it in the zodb wouldn't it make sense to store it in a seperate place so you can at least use a history free storage? It also means its easy to dispose of all that data if you want.

As said: the current approach works for us without any need for change.

It might make sense consolidate all approaches into own tool with a more pluggable storage backend. On the other hand I do not want to implement a generic storage API since I want to be able display and filter logger entries easily.
I am currently discussing this issue with another customer with similar needs. Perhaps there could be a funding to more general solution.

Andreas

@zopyx also its a personal preference but these days I much prefer adding features to generalise other peoples plugins than let 3 alternatives that each make slightly different tradeoffs exist in the eco system... despite that taking longer to do.

you could seperate the viewer so it went with your pluggable storage rather than with the collector. You are right, it would be a mistake to make the viewer pluggable.

I am also in the need of such a log. My evaluation of the current implementations was leading me to the conclusion to write my own implementation.

So I will implement a kind of audit log using souper, which is in fact super easy to do.
Souper stores inside ZODB (and its transaction mechanism), but does not pollute the catalog, is queryable and can live on its own mount-point.

My use case is a log of access to a content subtree with very sensible personal data - this is requested by law. With the need of access logging of

  • login,
  • add,
  • edit and
  • read,

I need to log a dataset such

  • the computer its accessed from (we use certificate based authentication on Apache level before the normal login on a per-machine base).
  • the username
  • date/time

I will start with the implementation mid/end of February. If anyone is interested I'd be super happy to discuss it (i.e. via Hangout).

I agree.

The major part would be to pack all collectors and available subscriber into one canonical package...then the collected stuff could be emitted to a well-defined channel or API.

Andreas

Also an interesting approach.

Andreas

Did you ever release this? I couldn't see it on pypi. We are also looking for a solution and aren't sure about either fingerpointing or auditlog. At the moment we thinking of taking the audit code from castlecms and putting that in its own package. It uses elastic and includes a report and download view. But I like the idea of support souper too.
We need this mainly for logging our own custom events and less for standard plone events (other than login/logout)

In fact I decided to use collective.fingerpointing - starting a new thing I have to maintain on my own while there is something out that almost targets my needs felt wrong.
Since collective.fingerpoiting can be extended easily all I had to do is to write some glue code and fix/enhance minor things in the package itself

I hate starting new packages too but I ruled out fingerpointing because it only has support for file logs, doesn't support multiple plone instances and the report system seemed too basic. Also unless you have a shared file system it won't work.

Plone Foundation Code of Conduct