Problem/Motivation
Sometimes we want to be able to log messages which contain encrypted data. We can't use watchdog for this and also we want to keep it seperated from all the other messages which watchdog generates so we can give access to supereditors to this logs.
Proposed resolution
We already have dvg_logger, which currently is only used for:
* log failed login attempts
* log the change of the test BSN number
If we expand this functionality a bit and create an UI, we will be able to enhance dvg_logger for our purposes.
Remaining tasks
* Add encrypted field to dvg_logger table
* add $encrypted parameter to _dvg_logger_register_log()
* create UI
* create permissions
* create update hook
User interface changes
New user interface for admins and supereditors at:
/admin/reports/dvg-logger
API changes
New parameter $encrypted:
_dvg_logger_register_log($type, $name, $encrypted = FALSE);
Data model changes
New field "encrypted" (boolean) in table dvg_logger.
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | dvg-fix_short_array_syntax-2930491-20.patch | 635 bytes | paulvandenburg |
| #14 | interdiff-2930491-13-14.txt | 558 bytes | paulvandenburg |
| #14 | dvg-custom_encrypted_logger-2930491-14.patch | 11.63 KB | paulvandenburg |
Comments
Comment #2
askibinski commentedComment #3
Danny.Wouters commentedThe patch works. Log messages with encrypted data are now logged in the dvg_logger table
Comment #4
askibinski commentedWe need to add a configurable option which types should be mailed. Now, all types are mailed in _dvg_logger_send_email() which would result in our encrypted entries also being mailed.
Comment #5
askibinski commentedComment #6
askibinski commentedNeeds work:
1. expand options to purge logs. Currently only 1 month, 2 months. Should be 1 to 7 days, 2 weeks, 1 month, etc.
2. our overview query currently fails if the messages are very large because of memory limits:
We aren't showing message any more in the table overview so this should be removed from the query.
Comment #7
Danny.Wouters commentedI created a new patch which adds additional time slot options to purge the logs. I also removed the 'message' field from the query
Comment #8
Danny.Wouters commentedI removed the changes to the .info file from the previous patch
Comment #9
heine commentedWhy the check_plain?
Message is no longer used here.
I wonder why this is t() and not format_string(). If translations are desired, the watchdog approach would be more appropriate.
Is it possible to show only a part of the message (if non-encrypted) in the overview table? That would make the overview more useful. If dvg_logger is also required for debugging using large data dumps, wouldn't it be better to separate messages, message variables & dump? Or in other words; what is the purpose of this module?
Comment #10
Danny.Wouters commentedThe function _dvg_logger_register_log didn't use the parameter $encrypted to encrypt the message.
I made a new patch to encrypt the message depending on the value of $encrypted
Comment #11
heine commentedIn addition to #9; dvg_logger_update_7002 uses schema. See https://www.drupal.org/node/150220 for why this will work now, but is not correct.
Comment #12
askibinski commented@heine the idea is to extend dvg_logger into a more generic solution for dvg specific logging and this patch is a first step but we need to separate into more types to make the overview and dvg_logger more useful.
The check_plain isn't needed indeed and $message was leftover code from an earlier version.
Comment #13
Danny.Wouters commented@Heine thanks for the review. I added your suggestions to a new pach
Comment #14
paulvandenburg commentedFixed @heine's feedback from #11.
I however took a different approach than the linked documentation.
This should mitigate the problem as well, without having to add redundant the schema definitions.
Comment #15
joshahubbers commentedComment #17
paulvandenburg commentedComment #18
paulvandenburg commentedComment #20
paulvandenburg commentedThis issue accidentally added the short array syntax. Until we've formally dropped php 5.6 support (soon?), we shouldn't do that.
I've already committed this, but here is the patch separately anyway.