After some more code digging and experiments I can answer my own question. A theme is a normal plugin and as such does not inherit any behavior from other plugins.
So you need to copy everything you need from the base theme library.js to your child theme. And of course, you need to declare client scripts explicitly.
Loading of missing templates from base theme is the only link between the base and the child theme.
Security logging?
-
So, there are certain events which should definitely be logged for administrative review. For example, if my plugin detects a socket request that seems maliciously invalid, it should be logged.
Right now I'm using winston.error and dumping the socket info / specific error info.
Is this correct? Should there be some other logging mechanism for potential attacks/malicious users? Ideally any time something like that occurs, the IP of the attacker should be dumped to the log.
-
Does this help? gh#150
closed Application event logging & auditing #150
-
Yeah, events.js seems like it should contain the functionality for this. It currently only logs UID, but a lot of those functions should probably log the IP of the triggering party as well.
It seems like the only way to do that is to have IP be a parameter for most of those calls. That's a little tedious.
my fantasy: events are logged to the db as well as flatfile, have severity/importance levels, contain as much info as possible about who triggered it if the logging fn is passed a socket or request object, there's hooks for events of high severity, by default sends email or notification to admins when high-sev occurs
