Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.According to the change to data protection ordinance in May 2018, a possibility of throttling the logging of sensitive remote instance data should be given.
There should be 2 Options:
1. Default DRD logging behavior.
2. DRD logging with metadata but without the response data (message/variables of watchdog-table).
- This one is kind of sensitive, because eg actions like collect information and projects status need to be saved to db to keep DRD alive.
- Thinking about that, it shouldn't be possible to skip logging for certain actions. Therefore it should be a method, that provides the possibility to skip loggin for 'some' actions, that are previously determined by configuration.
A checkbox should define, which option gets processed. If checked, #2 happens, but the response data gets stored temporarily (not in db) inside a cookie (to view the data, an additional tab 'Outputs' should be created, where only cookie data gets rendered.). Otherwise normal default behavior.
That checkbox should be settable globally (all actions on all hosts) and per action.
I've already begun with the implementation of that and will soon post a patch and documentation.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | dblog-throttle-2932073.patch | 15 KB | drupatz |
Comments
Comment #2
drupatz CreditAttribution: drupatz commentedComment #3
drupatz CreditAttribution: drupatz commentedComment #4
drupatz CreditAttribution: drupatz commentedComment #5
drupatz CreditAttribution: drupatz commentedSo now, following is done:
-New menu item: Outputs (drd.links.menu.yml)
-New tab: Outputs (drd.links.task.yml)
-New route: Outputs (drd.routing.yml)
-New template: drd-outputs.html.twig (registered in drd.module)
-New Controller: OutputController (rendering of cookie values) (Controller/OutputController.php)
-New general setting for allowance of skipping actions: Checkbox and dropdown (Form/Settings.php)
-New logic for removing @response from log message and creating cookie, if action skipped from logging (Plugin/Action/Base.php)
-New dynamic checkbox for skip logging per action, only showing when selected in general settings (RemoteActions.php)
Todo:
-Think about a generic and readable output, as existing and future action-response may differ from structure (currently only arrays are translated into markup)
-Check, how a recently set cookie could be read immediately to allow multiple actions per domain per cron run (currently that's not possible, because the set cookie isn't saved yet, when the next action is processed)
-Determine actions, that mustn't be skipped from logging.
Comment #6
drupatz CreditAttribution: drupatz commentedComment #7
jurgenhaasThis needs some more thoughts before we should start implementation here.
First of all, storing anything in cookies should be a no-go because actions will be performed by CLIs as well (drush or console) and they have no access to any cookies content which live in the browser only.
With regard to your usage of the word logging I wonder what exactly is meant. Is it the logging in watchdog or is it the storage of collected information from remote site to be display in the domain details view?
If we are talking about logging to watchdog, I'd argue that this feature should never be used in production and hence nothing would be logged at all. By definition, that's the best data protection: no to collect the data in the first place ;-)
However, if we're ralking about the storage and display of the collected information for the domain details view, then the following thoughts apply. I wonder what makes the difference between storage as DRD does it now and of what you're calling temporary storage. Is the difference only where that data is stored? E.g. in the database versus somewhere else? Where is that "somewhere else" then? Or is it about the duration of the storage? Note, DRD stores that data in cache only anyway and you could easily configure your production system such that cache won't live in the database, so you would get to that result without any programming at all.
From my perspective, the location of the storage doesn't matter here.
What may be relevant is the question if that data is stored in plain text or in encrypted format. Currently, that data is cached in plain text but it would be very easy to just encrypt all that with the already available encryption framework.
Also, let's create a list of data that is perceived to be sensitive and falling under the GDPR - baring in mind that onyl system administrators should have access to DRD and they have access to that information in any case, regardless of what we change in the module. From my point of view, GDPR compliance is about protecting information from unintended access and if that's the case, then I'm convinced that encrytion is the answer to the problem.
Comment #8
jurgenhaashttps://gitlab.com/drupalspoons/drd/-/issues/38