3 May 2018

windows 10 logon/logoff tracking by filtering system events

When I'm late filling in my timesheets, it always is a headache to remember which hours I spent working. My windows event viewer (eventvwr.msc) can be a help but the logs are too crowded.
The events related to logon/logoff are polluted with plenty of events from system services.
So I ventured to create a filter only showing the events relating to my user. This requires XML filtering based on XPATH.

  1.  Create a new custom event view
    1.  right click the security category and select Create Custom View...
    2.  enter the event ID's you want to filter. For logon/logoff these are 4624, 4634 and 4647
      1. You can get the id's by examining your events or from this MSDN page.
UPDATE: I'm often not logging off when I'm away, and this method does not log system sleep. Instead of monitoring logon/logoff I made a new filter that logs By source on event source Power-Troubleshooter. The details in the logs show the time the system went to sleep and woke up. The time in the details are in Zulu time (UTC+0), so they are some hours of from the real time, but given that the event time is correct, this is easy to deal with. The post remains interesting as a general explanation of event filtering, so I just added this update, and did not modify the general procedure
  1. Modify the base filter. 
    1. There is a field for filtering on the user name in the filter definition form, but that did not work. By clicking the XML tab we can edit the XML filter definition. Take care: you will not be able to edit the filter using the graphical user interface anymore after that.
    2. I added user filtering in the XML. This is my filter
    3. <QueryList>
        <Query Id="0" Path="Security">
          <Select Path="Security">
            *[System[( EventID=4624 or EventID=4634 or EventID=4647)] 
              and EventData[Data[@Name='TargetUsername']='jan']]
    4. I saved the filter and provided a name for the new custom filter. 
  2. We're done
Now you might wonder where I got the name of the field I needed to filter on from.  You can get the XML element names by examining the event in your logs
  1. In eventviewer, pick a logon event of logon type 2. More info on logon events...
  2. Select the event and in the bottom  half of the window you see the details
  3. Select the Details Tab, then the XML view button. This shows you the name/value pairs on which you can filter. I  want to filter on my user, so I'll need the SubjectUserName field.
On this Micorosoft technet page you find more info on XML event filtering.

2 May 2018

Node.js 10 released

Node.js 10 is releaed and will become the long term support version (replacing Node 8) in october 2018.

  • ES6 module support: 
    • given the ubiquity of node.js native modules (CommonJS) this was a hard nut to crack
    • Both systems provide and use module elements differently
      • Node.js modules work with module.exports and require 
      • EJS modules work with export and import
    • a difference between both module systems is that node modules load synchronously and ES6 modules load asynchronously. Tools bridging both worlds like webpack load ES6 modules syncronously into Node.js. These tools have allowed isomorphic javascript, running both in the browser and in Node. The node team has not gone this way and stuck to the standard: they load ES6 modules synchronously.
    • Node 10 allows usage of ES6 modules only in files with the new .mjs extension (module javascript). So .js files keep on using module.exports and require. 
    • How do you access a module from the other module universe?
      • You can import from a Node .js file into a ES6 .mjs file, but you can only use a default import. That is logical, as Node's module.exports only exports one thing. This one thing can be an object or a function, that can encapsulate more stuff.
      • You can import from a .mjs file into a Node .js file, but only by explicitly making the import asynchronous using await import(). Again this seems a logical choice.
      • This image from a Medium article  sums it up nicely
      • If you import a file without an extension Node will first look for a .mjs file. If it does not find it, it will look for a .js file. This leaves the door open to using your ES6 .js files, without renaming them.
    • This seems to be a workable system, but I'm not sure I like the degradation of ES6 modules to second class .mjs citizens.  Well, this is a work in progress, and I think for now the Node team is awating the reaction from the developer community
  • API changes
    • fs.promises: fs functions returning promises without having to use util.promisify()!
    • standard numeric codes for error messages
    • console.table
  • npm 6
    • better security and new npm audit command to check a package for vulnerabilities
    • warnings if you download a package with security issues
    • speed bump