DEV Community: Warren

How to grant users rights to manage services

Warren — Fri, 27 Jan 2023 12:50:58 +0000

Chances are if you've been looking at how to grant a Windows user account or group the permissions needed to start/stop or otherwise control a service then you've seen MS's article on doing so. Trouble is it seems to be ancient, certainly the tools like Subinacl.exe are so old that most of the search engine links for it end up directing you to the wayback machine to get hold of it. No thanks! So I ended up in a rabbit hole of posts but have figured it out.

SIDs, DACLs, SACLs, oh my!

If you've never heard of any of these before, don't worry, you're not the only one.
Security IDentifiers (SID) are used to identify anything you can assign permissions to, e.g. users, groups, etc. MS refers to these as "trustees".
Discretionary Access Control Lists (DACL) are used to control grant/deny permissions to a trustee for accessing the related securable (in our case service).
System Access Control Lists (SACL) are used for controlling what access attempts get logged. We will not be changing these, but the process is essentially the same as as changing DACLs.

A SID is an ID that describes authority information for a trustee. More details can be found by reading Security identifier architecture. They look something like S-1-5-32-544 or S-1-5-27-8351948176-95729385651-85920185638-195.
An ACL is a string containing groups of permissions and the group they apply to.

That's funny if you've seen the show, and if you haven't you should Red Dwarf is awesome

tldr; We're going to get a SID for the account/group we want to give permissions to, a DACL for the service we want to control, and we're going to edit the DACL to include permissions for our SID.

Getting the Service DACL

To get the ACLs for the service we're going to use the sc.exe sdshow command. Run sc.exe sdshow "Wibble" where "Wibble" is the name of your service.
You should get a completely unintelligible string like

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Interpreting the ACL

You see the D: that means that section is the start of the DACL. Later on there's a S:, and yes, that's the start of the SACL.
Let's focus on the DACL

Interpreting the DACL

(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)

Believe it or not that actually has meaning, and isn't the result of some sort of binary conversion gone wrong. It's written using something called Security Descriptor Definition Language (SDDL) which uses something else called Access Control Entry (ACE) strings.
This is possibly the least accessible, most obscure thing I've come across in >30 years of using Windows, but mostly because the documentation is all over the place. Once you have a key, it actually becomes fairly easy to decode, so lets do that.

Each of the sections in the brackets are granting permissions to a different group. These are the ACE strings mentioned above. Lets take the first one

A;;CCLCSWRPWPDTLOCRRC;;;SY

The first character will either be A for "Allow" or D for "Deny". In this case these are the allowed permissions.
The last two characters are telling us which group that section applied to. See the "SDDL users and groups" section on this summary of SDDL for a key. So SY tells us these are the permissions for the "Local System".
The middle bit are the sets of permissions. For this you'd need the "SDDL access rights" section of the above article, but the codes are all related to registry key permissions, and still need translating into what that will do to the service. For that there's 👇 which I found in this old knowledgebase article.

Pair Right or permission
CC QueryConf
DC ChangeConf
LC QueryStat
SW EnumDeps
RP Start
WP Stop
DT Pause
LO Interrogate
CR UserDefined
GA GenericAll
GX GenericExecute
GW GenericWrite
GR GenericRead
SD Del
RC RCtl
WD WDac
WO WOwn

So CCLCSWRPWPDTLOCRRC means the group will have the QueryConf, QueryStat, EnumDeps, Start, Stop, Pause, Interrogate, UserDefined, and RCtl permissions. I don't have a clue what half of those are if I'm honest, because I saw what I wanted, namely Start, Stop, Pause, Interrogate.

So an ACE to grant permissions to start/stop/pause and interrogate the service would look like

A;;RPWPDTLO;;;???

Ah, not quite there yet, we still don't know the SID for the account we want to use. That's what will take the place of the ??? in our ACE.

Getting a SID

We can use the PowerShell Get-WmiObject commandlet to get the SID for the group we want to apply the permissions to.

(Get-WmiObject win32_group | Where-Object { $_.Name -eq "NameOfUserGroupThatNeedsPermissionForOurService"} ).SID

That should give you the SID to go in our ACE string.

Putting it together

Combining our ACE string with the SID now gives us

A;;RPWPDTLO;;;S-1-5-27-8351948176-95729385651-85920185638-195

Take the ACL and add that inside a set of brackets in the D: part.

D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPDTLO;;;S-1-5-27-8351948176-95729385651-85920185638-195)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

And now for the final step (well done for getting this far, it's been a long one). Assign the permissions using sc.exe sdset.

sc.exe sdset "Wibble" "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPDTLO;;;S-1-5-27-8351948176-95729385651-85920185638-195)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

Simple as that 🫤

Github Actions

Warren — Fri, 13 Jan 2023 11:40:17 +0000

I've been using different build systems for years, but after playing with github actions quite a bit there was still some things that I was only managing based on trial and error. I've written this guide to try and fill in those gaps. If you've been through the Quickstart for GitHub Actions and Understanding GitHub Actions documentation but still have some questions I'm hoping this post will answer some of them.

First some definitions:

Workflows are combinations of jobs
Jobs are combinations of steps that are run on a virtual machine, they can even be a workflow of their own
Steps are either actions or shell commands

Sharing data in your workflow

This was one of the bits that I felt the documentation didn't explain clearly enough. All the information is there, but spread across multiple pages and can take quite a while to put it all together.

Environment variable types

It's worth baring in mind that because most of what follows uses environment variables under the hood it is a string, so even though the value could be 'true' or 'false' you would need an expression that explicitly compares it to those values. e.g. if: env.isTag == 'true' would work, but if: env.isTag alone would not.

Inputs to workflows however can be string, number or boolean types.

Sharing data between steps in a job

If one of your steps has an output that you need in a later step within the same job you can set it as an environment variable. This is done by sending a statement setting it to the $GITHUB_ENV file. A minimal demonstration of this is:

steps:
  - name: Set myValue
    run: echo "myValue=wibble" >> $GITHUB_ENV
  - name: Echo myValue
    run: echo "$myValue"

Ofcourse the above isn't that useful, the wibble part would usually be a calculated value. You would usually use some of the calculate the value from some other environment variables. You can either calculate your value in the bash script, e.g.

env:
  wibble: wibble
steps:
  - name: Set myValue
    run: echo "myValue=$GITHUB_REF_NAME-$wibble" >> $GITHUB_ENV

or you can use the javascript context ${{ }} and any of the expressions or contexts to calculate your value, e.g.

env:
  wibble: wibble
steps:
  - name: Set myValue
    run: echo "myValue=${{ github.ref_name + "-" + env.wibble }} >> $GITHUB_ENV

These two blocks should be equivalent, but the expressions mean I generally use the JS version.

The key bit is that it is sent to the $GITHUB_ENV file. This is what will make it available as an environment variable to the steps that follow it. But only within that job. What if you want to share that value with different jobs?

Sharing data between jobs within a workflow

In the above you used the $GITHUB_ENV file to make a value available to later steps, but if you want to share a value to a different job you need to use the $GITHUB_OUTPUTS file instead. But that would be too easy. In addition you also need to declare it as an output.

Within your job you will need to add an outputs section that uses the JS context to access the value you will output. You do this by accessing the steps context object. The step that you use will now need an id so that you can access it through steps.<stepId>.
For example, if you want a job that outputs a value that says if this build was triggered by a tag:

jobs:
  isTagJob:
    runs-on: ubuntu-latest
  outputs:
    isTag: ${{ steps.set_istag.outputs.isTag }}
  steps:
    - id: set_istag   # step id used to find the output above
      name: Set isTag # name that will appear in the logging for this section
      run: echo "isTag=${{ startsWith(github.ref, 'refs/tags/') }}" >> $GITHUB_OUTPUT

This will make the isTag value available to any jobs dependant on this one through the needs context. The format is needs.<jobId>.outputs.<outputName> so the above would be needs.isTagJob.outputs.isTag. For example the following will only run the announce_tag step if isTag is 'true'.

...
  announceTag:
    runs-on: ubuntu-latest
    needs: [isTagJob] # This makes it dependent on the `isTagJob` job above
    steps:
      - id: announce_tag
        name: Announce tag
        if: needs.isTag.outputs.isTag == 'true'
        run: echo ::notice::This build is for a tag

Sharing data to reusable workflows

Workflows that are called by other workflows use workflow_call as their on trigger. You can pass values to these workflows by defining inputs in that workflow and passing the values in using with in the calling workflow.

For example the file .github/workflows/build-dotnet.yml shown below takes two inputs projectDir and isTag and then uses them in it's jobs.

name: Build Dotnet

on:
  workflow_call:
    inputs:
      projectDir:
        required: true
        type: string
      isTag:
        required: true
        type: boolean

jobs:
  build-code:
    runs-on: ubuntu-latest
    steps:
      - id: build
        name: "Build ${{ inputs.projectDir}}"
        run: dotnet build ${{ inputs.projectDir}}
      - id: push_artifact
        name: "Push ${{ inputs.projectDir}} artifact"
        if: inputs.isTag # the input is a boolean so don't need to compare to `'true'` like with env vars.
        uses: actions/upload-artifact@v3
          with:
            name: ${{ inputs.projectDir }}
            path: ./temp/${{ inputs.projectDir}}/**/*

The calling workflow will need to ensure it provides the values correctly so that this workflow can use them. The calling workflow code could look like:

name: Build
on:
    push:
jobs:
  isTagJob:
    runs-on: ubuntu-latest
    outputs:
      isTag: ${{ steps.set_istag.outputs.isTag }}
    steps:
      - id: set_istag   # step id used to find the output above
        name: Set isTag # name that will appear in the logging for this section
        run: echo "isTag=${{ startsWith(github.ref, 'refs/tags/') }}" >> $GITHUB_OUTPUT
  build-dotnet-proj-a:
    needs: [isTagJob]
    uses: ./.github/workflows/build-dotnet.yml
    with:
      projectDir: projects/projectA
      isTag: ${{needs.isTagJob.outputs.isTag == 'true'}}
  build-dotnet-proj-b:
    needs: [isTagJob]
    uses: ./.github/workflows/build-dotnet.yml
    with:
      projectDir: projects/projectB
      isTag: ${{needs.isTagJob.outputs.isTag == 'true'}}

The same syntax for inputs in reusable workflows is also used actions.

Linking to a Giphy gif

Warren — Wed, 24 Aug 2022 09:04:03 +0000

Once you've found the gif you want, e.g. ⬇️ the Platypus gif page.

Chances are you've tried right clicking on the image and opening it in a new page, or copying the url only to find you end up not with the image but another web page with the platypus gif on it.

So to get a link to the gif itself go back to the first link, the Platypus gif page's URL is https://giphy.com/gifs/video-siz-platypus-ETV4MRojrqsve and the bit we need is the code on the end after the final -, i.e. ETV4MRojrqsve.
Put that code in to the url https://media.giphy.com/media/{code}/giphy.gif
and voila, you have a link to an actual gif that can be downloaded or embedded in markdown, html, etc.
e.g.
https://media.giphy.com/media/ETV4MRojrqsve/giphy.gif links to ⬇️

How to use reduce in javascript

Warren — Wed, 16 Dec 2020 13:49:33 +0000

How to use `reduce` in javascript

Reduce is one of those functions that seems to get a marmite reaction. Some people love it, and others hate it.
I'm primarily a .NET developer and am a big fan of LINQ when it comes to collections. The two most commonly used methods from this library are likely to be Select and Where, which in JavaScript correspond to map and filter, and are used in pretty much the same way.

const values = [1, 2, 3, 4]
var doubled = values.Select(x => 2*x); // returns [2, 4, 6, 8]
var odds = values.Where(X => x % 2 != 0); // returns [1, 3]

const values = [1, 2, 3, 4]
const doubled = values.map(x => 2*x) // returns [2, 4, 6, 8]
const odds = values.filter(x => x % 2 !== 0) // returns [1, 3]

But when I first came across reduce I realised I didn't know what the LINQ equivalent was. It's Aggregate btw, but the reason I didn't know is because I had simply never needed it. This isn't because this type of function is useless, but because LINQ provides a host of other more specific aggregate functions, especially if you also use MoreLINQ as we do.

Useful Aggregates

The sort of aggregate functions I immediately started to use reduce for were things like Sum, Min, Max, Distinct, etc.

The same result can usually be achieved by using a forEach loop and there's no reason why you can't. My preference for using reduce is that the code often looks very similar, but is still a pure function that doesn't rely on mutable variables.

Sum

Consider these approaches to adding an array of numbers using forEach and reduce (there will be a full explanation of the code in the next section).

`forEach`

let total = 0;
values.forEach(x => {
    total += x
})

`reduce`

const total = values.reduce((prev, curr) => {
    return prev + curr
}, 0)

The forEach depends on a variable value which can be changed, and wraps this in a closure allowing it to be progressively added to, where the reduce implementation is a pure function the result of which goes directly in to an immutable constant.

Reduce

The reduce function takes in two arguments

The reducer
An optional initial value

The reducer is the part that confuses most people. The reducer is a function that will perform the aggregation one value at a time. If you've seen the MDN documentation then you know that the reducer can accept up to 4 parameters, but typically you only need the first two. I always call these two parameters prev, and curr. It's worth noting though that prev is not the previous value in the array but the previous value returned by the reducer. Continuing with summing as an example:

Sum

const values = [1, 2, 3, 4]
const reducer = (prev, curr) => {
    return prev + curr
}
const total = values.reduce(reducer, 0)

I've extracted the reducer into a separate variable just to make it clearer which part of the above I'm talking about. This reducer function will be called once for each value in the array.

The first time we come in prev takes the value of the second parameter passed to reduce, in this case 0 (If we didn't specify an initial value it would be undefined). curr would be the first value from the array. It adds the two and returns the result. The next time the reducer is called this result will become the prev value. See the table below for what happens to each parameter is it loops through the array.

Loop #	`prev` value	`curr` value	Returned value
1	0	1	1
2	1	2	3
3	3	3	6
4	6	4	10

The final result 10 would be returned from the reduce function and stored in the total constant.

Max

Another example, this time we'll find the greatest number in an array of numbers.

const values = [15, 6, 12, 24, 3, 11]
const max = values.reduce((prev, curr) => {
    return prev > curr ? prev : curr
})

This time our table of values will look like:

Loop #	`prev` value	`curr` value	Returned value
1	`undefined`	15	15
2	15	6	15
3	15	12	15
4	15	24	24
5	24	3	24
6	24	11	24

With 24 as our final result.

Aggregates with different types to the array

So far the return type of our reducer has been the same as the input types, which means that both prev and curr parameters have also been of the same type, but this is not always the case.

In this example we'll convert an array of objects into a javascript object. This can be useful for using it as a dictionary.

const values = [
    {id: 106, name: "Wibble"},
    {id: 357, name: "Wobble"},
    {id: 652, name: "Flibble"}
]

const valuesDictionary = values.reduce((prev, curr) => {
    return {
        ...prev,
        [curr.id]: curr
    }
}, {})

console.log(valuesDictionary[652]) // outputs "{id: 652, name: "Flibble"}"

This example makes use of the spread operator to take the properties of the prev parameter and add them all to the new object the reducer returns. The end result is a JS object which you can use as a dictionary to look up each item by its id.

The above achieves the same result as .NET's ToDictionary method.

Using HTTPS with create react app

Warren — Thu, 16 Jul 2020 08:04:46 +0000

Using HTTPS with create react app

It's been a while since I first wrote about using HTTPS with react create app, and since then things have changed, so here's an updated set of instructions.

A new feature has been added to react scripts that allow us to specify a certificate file without needing to modify the node_modules contents as my previous solution required. You'll need to ensure you have at least version 3.4.0 of react-scripts to be able to use this feature.

Creating the certificate

To create the certificate you'll need openssl. You can install it using chocolatey by running choco install openssl. Start by creating the configuration file. Save the following as certificate.conf

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = GB  # Enter 2 digit country code here
O = My Company # Enter company name
CN = localhost
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost

Next up run the following command to create the certificate and key.

openssl req -x509 -newkey rsa:4096 -sha256 -keyout certificate.key -out certificate.crt -days 365 -config certificate.conf -new -nodes

Take the two files and store them in the root of your app.

Using the certificate

In the root of your app create a file called .env if you don't have one already. This file can be used for storing environment variables to be used by the react-scripts for various settings.
Add the following to it

HTTPS=true
SSL_CRT_FILE=certificate.crt
SSL_KEY_FILE=certificate.key

That's it. When you run yarn start it will use these environment variables to retrieve the certificate and use it for the webpack-dev-server. At this point you'll still be getting a certificate warning in your browser.

Install the certificate

You need to install the certificate to a trusted root location.

In Windows open the start menu and type "certificates".
Select "Manage Computer Certificates"
Expand "Trusted Root Ceritification Authorities"
Right click on "Certificates" and select "All Tasks" -> "Import".
Click next
Enter the path for the crt file.
Proceed through the next few screens to import the certificate

Finally those pesky browser warnings should be gone. You'll be able to develop away for the next year. Note that you can change the -days value in the openssl req command, but the current maximum most browsers will accept is 825, and just 368 days in Safari. When the year is up, just come back here and remind yourself how it works. That's what I'll be doing ;)

Forms in React

Warren — Mon, 13 Jul 2020 14:22:01 +0000

Forms in React

Forms have always sucked a bit in React. Which is pretty frustrating given how much of web interactions are done with them.

Formik tried to solve this and did a pretty good job, until you wanted to do something a bit more complicated. For example I had a form where the user would select a value from a dropdown which triggers an API request to get the options for the next dropdown. If there was only a single option returned then I needed to set the value to that option. This proved far more complicated than I had hoped.

Hooks have also made the situation much easier to deal with, but if you're using lots of useState calls to store individual fields then there can be quite a lot of boiler plate just to update a form field, and that's before you've considered doing other tasks such as validation.

function HookForm() {
    const [ firstName, setFirstName ] = useState("")
    const handleFirstNameOnChange = (e) => setFirstName(e.target.value)
    const [ lastName, setLastName ] = useState("")
    const handleLastNameOnChange = (e) => setLastName(e.target.value)
    ...
}

So what's the new way

I whipped up a (very) quick proof of concept over the weekend, and have called it FormUp (Reform was taken).
The idea is to declare the form using a fluent API in a similar way to how Yup validation schema's are written. The result from this hook will then give you everything that you need to not only render the form, but also to update any of the values and which fields have error messages etc.

const { fields, form } = FormUp.useFormUp({
  name: FormUp.text(""),
  email: FormUp.email(""),
  dob: FormUp.date(""),
}, {
  onSubmit: (e) => console.log("Submitted"),
});
...
return (
  <FormUp.Form form={form}>
    <FormUp.Input field={fields.name} />
    <FormUp.Input field={fields.email} />
    <FormUp.Input field={fields.dob} />
    <button type="submit">Submit</button>
  </FormUp.Form>
)

What's next

It's still very raw and certainly not ready for anyone to use. But I'm hoping to quickly add features to enable validation, value management. Let me know what you think. Is this likely to be useful or are we happy with Formik?

Signing PowerShell scripts

Warren — Fri, 06 Mar 2020 11:01:08 +0000

Signing PowerShell scripts

I ❤️ PowerShell. It's a really useful tool for automating those tasks you do multiple times. But it can also be a gaping security hole if you let it.

PowerShell allows you to administer almost everything on your machine, so there is a lot of damage that could be done by someone able to run malicious scripts in your environments.

Previously confined to just Windows, since version 6 and now with the release of PowerShell 7.0, it can also be deployed on Linux and MacOS. However this article talks about Execution Policies which cannot be changed in non Windows environments so will provide no benefit to Linux/MacOS users (sorry).

Execution Policies

One way you can restrict the ability to run scripts in your Windows environments is to use PowerShell's execution policies. The tldr is that they can be used to restrict the scripts that will run in the environment. The options available from least secure to most secure are:

Bypass

Nothing is blocked.

Unrestricted (Always applies on Non-Windows machines)

Same as ByPass but prompts the user before running scripts from the internet.

RemoteSigned (default for Windows Servers)

Scripts that have been downloaded from the internet can only be run if they are signed. Scripts written on the machine can be run

AllSigned

All scripts must be signed before they will run

Restricted (default for Windows Clients)

Prevents running scripts. Can only run individual commands.

Running Scripts

So you want to run your own PowerShell scripts on your server. But you're getting a PSSecurityException like the following.

PS C:\Users\Administrator\Downloads> .\wibble.ps1
.\wibble.ps1 : File .\wibble.ps1 cannot be loaded. The file
.\wibble.ps1 is not digitally signed. You cannot run this script on the current system.
For more information about running scripts and setting execution policy, see about_Execution_Policies at
http://go.microsoft.com/fwlink/?LinkID=135170.
At line:1 char:1
+ .\wibble.ps1
+ ~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

One way to resolve this issue is to change the execution policy using the Set-ExecutionPolicy command and reduce the security of the machine. This is a generally a bad idea.

Personally, I would never use anything less secure than RemoteSigned on a server, but AllSigned ideally.

What is a script signature?

Presumably you want to maintain the security of the machine and not open up a vulnerability so the option left to you is to sign your scripts.

Signing a script means that someone with access to the private key for a code signing certificate has added a signature block at the end of the script file.

function Get-Wibble {
    return "Wibble"
}
# SIG # Begin signature block
# vpnIUpm2XxLRhU1no0iuA62xKxYzR6m95z9Ax21ppeTC9NoRd8ocoSGr1zAd
# qlMOlz4lZoVWR4ZmtdCgzde1dVxzv4jjHb6ziDiY2o05UXswD2bl6XaOrUpd
# Li0Qjg3d3y2r1nrpO8hos906bgXQswysvouegUJcpt8ftmqBKfEYNeBgnBFm
# SIG # End signature block

(Example only. The signature block is usually much longer)

The signature block will contain a hash of the script that has been encrypted using the private key. When attempting to run the script this is decrypted using the public key and compared to the actual hash. If it matches then we can confirm that the script has not been tampered with as the hash would change as soon as that happened.

Self Signing certificates

If your scripts are only going to be run by machines in your organisation then you will most likely be able to self sign the certificates. The alternative is to spend $$$ and buy a code signing certificate each year.

Self signing means you will generate the certificate yourself and sign the scripts using that.

How to create a self signing certificate

PowerShell has the very useful New-SelfSignedCertificate command for producing self signed certificates. We can then export them and place them in different stores.

By default the command will create a certificate that expires after 1 year. You can change this using the -NotAfter parameter and providing it the date you wish the certificate to expire.

To create a certificate fire up a PowerShell session and run the following

$CertificateName = Read-Host "Input your certificate name"
$OutputPFXPath  = "$CertificateName.pfx"
$OutputCERPath = "$CertificateName.cer"
$Password = Get-Credential -UserName Certificate -Message "Enter a secure password:"

$certificate = New-SelfSignedCertificate -subject $CertificateName -Type CodeSigningCert -CertStoreLocation "cert:\CurrentUser\My"
$pfxCertificate = Export-PfxCertificate $certificate -FilePath $OutputPFXPath -password $Password.password
Export-Certificate -Cert $certificate -FilePath $OutputCERPath
Import-PfxCertificate $pfxCertificate -CertStoreLocation cert:\CurrentUser\Root -Password $password.password
Write-Output "Private Certificate '$CertificateName' exported to $OutputPFXPath"
Write-Output "Public Certificate '$CertificateName' exported to $OutputCERPath"

This will create the certificate and export it to two separate files with the extensions .pfx and .cer.

PFX

The PFX certificate is the one that will need to be installed on the machines that will be doing the signing. In our case that is each of our developers machines.

It should be installed in to the cert:\CurrentUser\Root store, also known as the "Trusted Root Certification Authorities" store.

This file should be kept somewhere secure. The password should then be secured separately (use a password manager). If a bad actor gets hold of both of these then they can sign their malicious scripts as if they were you.

CER

The CER certificate file is what you're going to have to install on the machines that will be running the scripts. This won't require a password to install but cannot be used to sign scripts. It only contains the public key used to decrypt the signature.

Because it doesn't contain the private key this certificate can be freely distributed to all environments that will be running the scripts.

This will need to be installed in two certificate stores on the machines that will be running the scripts; The cert:\LocalMachine\Root and cert:\LocalMachine\TrustedPublisher stores.

Signing a script

The Set-AuthenticodeSignature function is provided to sign the scripts. We need to pass in the path to the script and the certificate from the store. We wrote a wrapper function that can sign the scripts.

function Set-ScriptSignatures {
    param (
        [string]
        $pathToScripts = "."
    )
    $certificateName = "PowerShell Signing Certificate"
    $scripts = Get-ChildItem -Path "$pathToScripts\*" -Include *.ps1, *.psm1 -Recurse

    $certificate = @(Get-ChildItem cert:\CurrentUser\My -codesign | Where-Object { 

    $_.issuer -like "*$certificateName*" } )[0]

    foreach ($script in $scripts)
    {
        Write-Host "Signing $script"
        Set-AuthenticodeSignature $script -Certificate $certificate
    }
}

The $certificateName variable should contain the name used when creating the certificate.

You can use the function by providing a path to the directory that contains the scripts and it will loop through them signing them all.

Once you've installed the scripts on the target machine you should now be able to run the run the scripts without any issues.

useCancellationToken: Avoid memory leaks in react

Warren — Mon, 18 Nov 2019 12:08:58 +0000

Inspired by Sophia Brant's article on Memory Leaks With React SetState I set about creating a reusable hook that can be used to mitigate not being able to cancel promises. I recommend reading that article first if you're unsure about what might cause memory leaks and the different approaches to avoiding them.

I have gone with an approach that creates a cancellation token which can either be cancelled manually or gets cancelled automatically if the component unmounts. FYI: I'm using typescript.

The scenario

We have a component which performs an asynchronous task, most likely a fetch, and then updates the component state afterwards, but it's possible the component has been unmounted before that request completes. If the state gets updated at this point we have a memory leak.

const [movies, setMovies] = useState([] as Movies[])
useEffect(() => {
    const action = async () => {
        const result = await fetch('http://example.com/movies.json')
        setMovies(result)
    }
    action()
}, [setMovies])

React doesn't support async lambdas in useEffect, so creating an async lambda within the lambda and calling it, as we do here, is a common workaround.
We're going to refactor this to use a cancellation token approach.

The token

First off we need a token that we can check for cancellation on, and which we can cancel.

interface CancellationToken {
    isCancelled: boolean
    cancel(): void
}

export function useCancellationToken(): CancellationToken {
    return useMemo(() => {
        const token = {
            isCancelled: false,
            cancel: () => {}
        }

        token.cancel = () => token.isCancelled = true

        return token as CancellationToken
    }, [])
}

This hook can be used to create a cancellation token when the component is mounted. The use of useMemo ensures it only gets created once so that when we cancel it, it stays cancelled.

I'm going to change the original use of useEffect to check if the token has been cancelled, and to call the cancel method on the token if the component is unmounted.

const [movies, setMovies] = useState([] as Movies[])
const cancellationToken = useCancellationToken()
useEffect(() => {
    const action = async () => {
        const result = await fetch('http://example.com/movies.json')
        if (cancellationToken.isCancelled) {
            return
        }
        setMovies(result)
    }
    action()
}, [setMovies, cancellationToken])
// If a function is returned from useEffect it is called when the component unmounts.
useEffect(() => () => cancellationToken.cancel(), [])

At this point we're avoiding the memory leaks by checking if the cancellation token has been cancelled. By returning a lambda to useEffect which calls cancellationToken.cancel() we're cancelling the token when the component is unmounted.

I went one step further and wrapped this bit of functionality in another hook, which I call useCancellableEffect. This also allows me to write the async lambda directly in to my hook without needing to use the workaround above.

The hook itself is:

export default function useCancellableEffect(action: () => void, dependencies: any[], cancellationToken: CancellationToken) {
    useEffect(() => {
        action()
        // eslint-disable-next-line
    }, [...dependencies, cancellationToken])
    useEffect(() => () => cancellationToken.cancel()
        // eslint-disable-next-line
    , [])
}

and the usage becomes

const [movies, setMovies] = useState([] as Movies[])
const cancellationToken = useCancellationToken()
useCancellableEffect(async () => {
    const result = await fetch('http://example.com/movies.json')
    if (cancellationToken.isCancelled) {
        return
    }
    setMovies(result)
}, [setMovies], cancellationToken)

which keeps all the boiler plate locked away in the hook, and only keeps what is relevant on the page. Ofcourse it is still up to the developer to check for cancellation and avoid memory leaks, but at least this helps make that easier. I also don't like the need to ... spread the dependencies and ignore the action dependency in the use of useEffect. If anyone comes up with a nice way of doing that without the need to disable the linter please let me know. The only approach I could think of for now was wrapping the action in useCallback, but that's more boilerplate again.

Note: An earlier version of this article didn't take in to account that useEffect calls the cleanup on every re render!!! The code snippets have been edited to account for this and handle it only when the component is unmounted.

Customising redux-api-middleware calls

Warren — Thu, 31 Oct 2019 10:08:01 +0000

I've been using the redux-api-middleware for contacting a secure API and because of the need for an Authorization header to be sent with each request found that I was needing to use function values for most of my actions such as the following.

{
    [RSAA]: {
        headers: state => {
            return {
                Authorization: state.authorizationToken
            }
        },
        endpoint: "/my/api/endpoint,
        method: "GET"
    }
}

The headers property will accept either an object, or a function which returns an object. In this case I was using the latter to retrieve the authorization token and adding it to each request. Continuing like this would mean each new request needed the same boilerplate to be repeated each time. To solve the problem I decided to use a custom redux middleware.

Custom Middleware

Middleware is formulated as a pipeline of many middlewares, each passing the dispatched action on to the next middleware before the reducers handle it. If we create a custom middleware that gets to the actions before the redux-api-middleware gets a chance then we can manipulate the dispatched action and make the changes apply to all of our requests removing the need for all that repeated code.

One solution here would be to create a function that adds the Authorization header. This could look something like this

const apiAuthorizationMiddleware = (store: any) => (next: any) => (action: any) => {
    // Pass to next middleware if not a redux-api-middleware action
    if (!action[RSAA]) {
        return next(action)
    }

    return {
        ...action,
        [RSAA]: {
            ...action[RSAA],
            headers: {
                ...action[RSAA].headers,
                Authorization: store.getState().authorizationToken
            }
        }
    }
}

But this would mean that you would always be adding that header. What about requests to different services? You don't want to be passing your "secure" API authorization token around all over the place. Instead what I'm going to do is replace the RSAA with a different value that will identify the requests I want to add the header to. This means my new action will look like this.

{
    [MY_AUTHORIZED_REQUEST]: {
        endpoint: "/my/api/endpoint,
        method: "GET"
    }
}

Note how I've replaced [RSAA] with a new value. That value is what we're going to change our custom middleware to look for.

import { RSAA } from 'redux-api-middleware'

export const MY_AUTHORIZED_REQUEST = "@@authorized_request"

export const apiAuthorizationMiddleware = (store: any) => (next: any) => (action: any) => {
    if (!action[MY_AUTHORIZED_REQUEST]) {
        return next(action)
    }

    const { [MY_AUTHORIZED_REQUEST]: request, ...newAction} = action

    const headers = request.headers ? {...request.headers} : {}
    const state = store.getState()
    headers["Authorization"] = state.authorizationToken

    request.headers = headers

    newAction[RSAA] = request
    return next(newAction)
}

export default MY_AUTHORIZED_REQUEST

Adding this middleware as well as the redux-api-middleware now means we can fetch [RSAA] requests without adding the authorization token header, and [MY_AUTHORIZED_REQUEST] requests with the authorization token header added from the value in the redux state.
This is just one example of what can be done with the middleware, you can change the request in any way you like, for example adding additional query string parameters, or changing the base url.

Setting up the store

Applying the custom middleware is done by adding it in to the pipeline ahead of the redux-api-middleware function along with any other middleware you use.

let createStoreWithMiddleware = applyMiddleware(apiAuthorizationMiddleware, apiMiddleware, routerMiddleware(history), thunkMiddleware)(createStore)
const store = createStoreWithMiddleware(reducer(history), initialState);

Ajax'd Javascript in dev tools

Warren — Mon, 07 Oct 2019 14:01:00 +0000

Honestly I'm mostly writing this as a note to my self since I have learnt about and then forgotten this particular trick several times over the last few years.

If you're loading javascript through ajax (quite common when working with ASP.NET MVC) then you can give a hint to the browser which enables it to open it in the dev tools with a specific file name. Just add //# sourceURL=filename.js before the closing </script> tag.

e.g.

<script>
    $(function() {
        console.log("wibble")
    })

    //# sourceURL=wibble.js
</script>

From the browser's dev tools you should now be able to open this file by searching for "wibble.js" (Ctrl+P brings up the search)

Securing IIS

Warren — Mon, 30 Sep 2019 20:41:19 +0000

Securing IIS

First up I recommend you head over to SSL Labs server test and enter the url of your site. Several tests will be run that check the certificate and cryptographic protocols of the site.

After a few minutes you'll be given a graded report

Not bad, but we can do better. If you scroll down to the configuration section you'll find a colour coded set of Protocols and Cipher suites. Any red entries have got to go.

Disabling protocols

The protocols we're going to disable are set by registry keys on the machine at HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. The following PowerShell will disable the keys, and then after a machine restart the protocols will no longer be available.

function Disable-InsecureProtocol {
    param (
        [parameter(Mandatory=$true)]
        [ValidateNotNullOrEmpty()]
        [string]
        $name
    )
    $protocolsPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
    $path = "$protocolsPath\$name"
    Ensure-Path "$path"
    Ensure-Path "$path\Client"
    New-ItemProperty -Path "$path\Client" -Name DisabledByDefault -Value 1 -PropertyType DWORD -Force | Out-Null
    Ensure-Path "$path\Server"
    New-ItemProperty -Path "$path\Server" -Name Enabled -Value 0 -PropertyType DWORD -Force | Out-Null
    Write-Information "Disabled $name protocol"
}

function Disable-InsecureProtocols {  
    Disable-InsecureProtocol "SSL 3.0"
    Disable-InsecureProtocol "TLS 1.0"
    Disable-InsecureProtocol "TLS 1.1"
}

Disable-InsecureProtocols

Disabling Cipher Suites

These will also disable the ciphers using the registry, this time at HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. For a complete list and more details see How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll

The following PowerShell will disable the suites that we found were giving us a poor score.

function Disable-InsecureCipher {
param (
        [parameter(Mandatory=$true)]
        [ValidateNotNullOrEmpty()]
        [string]
        $name
    )

    $ciphersPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers"

    $Writable = $True
    $Key = (Get-Item HKLM:\).OpenSubKey("SYSTEM", $Writable).CreateSubKey("CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\$name")
    $Key.SetValue("Enabled", "0", [Microsoft.Win32.RegistryValueKind]::DWORD)
    Write-Information "Disabled $name ciphers"
}

function Disable-InsecureCiphers {
    Disable-InsecureCipher "RC4 128/128"
    Disable-InsecureCipher "Triple DES 168"
}

Disable-InsecureCiphers

After running both of these scripts (and restarting the machine) your grade should have improved greatly.

Using HTTPS with react create app (Windows)

Warren — Wed, 24 Jul 2019 10:00:16 +0000

Using HTTPS with react create app

New Version

There's an updated version of this article, which uses a new feature release in react-scripts v3.4.0.

Reasoning

There are many reasons why you may want to develop against a website using https. For us we deploy to IIS and our web.config is set up to automatically redirect all http traffic to https, and we didn't want to have to override this in dev. This keeps our dev environment more similar to what we have in production.

Enabling https

This is the easy step. create-react-app, or more accurately react-scripts, will automatically enable https when you run the start command with an environment variable called HTTPS set to "true". After you've set this environment variable the next time you run npm start or yarn start the webpack dev server will start up with the https option enabled. This automatically creates a self signed certificate with a 30 day expiry. However:

The certificate is not trusted so you will always get a warning. The link above describes how you can create your own certificates and use them with webpack dev server, however because of the way react scripts works you won't be able to pass in the variables that specify which certificate to use nor any passphrase used to secure the certificate.

Creating a certificate that will be used

The webpack dev server can use both pem files and pfx files. A pfx file would need us to pass in the passphrase which we can't do, so we have to use pem files. This isn't as straightforward a process as you would hope in windows. I found that I had to export a pfx file and extract the key and certificate separately before putting them both in to the same pem file. This is needed because the webpack dev server will automatically check for these in a file called "server.pem" located in the ssl folder of its directory (i.e. "./node_modules/webpack-dev-server/ssl/server.pem"). I wrote the following script to achieve this and save the pem file in the desired location. You'll need openssl installed.



Write-Host "Creating https certificate"

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname localhost
$password = "AnyPassword"
$securePassword = ConvertTo-SecureString -String $password -Force -AsPlainText

$pfxPath = "./localhost.pfx"
$outPath = "./node_modules/webpack-dev-server/ssl/server.pem"
Export-PfxCertificate -Cert $certificate -FilePath $pfxPath -Password $securePassword | Out-Null
Import-PfxCertificate -Password $securePassword -FilePath $pfxPath -CertStoreLocation Cert:\LocalMachine\Root | Out-Null

$keyPath = "./localhost-key.pem"
$certPath = "./localhost.pem"

openssl pkcs12 -in $pfxPath -nocerts -out $keyPath -nodes -passin pass:$password
openssl pkcs12 -in $pfxPath -nokeys -out $certPath -nodes -passin pass:$password

$key = Get-Content ./localhost-key.pem
$cert = Get-Content ./localhost.pem
$key + $cert | Out-File $outPath -Encoding ASCII

Write-Host "Https certificate written to $outPath"

I saved this script in a file called "certificates.ps1" in the root of my project folder. If you run this script once it will create the pem file and put it in the correct location. If you try yarn start after running this the warning should disappear and your site will load. However, we are not finished. The next time your node_modules directory gets cleaned the certificate will be lost. Or if you never clean it will expire in a year.

Running the script

Open up your package.json file and find the "scripts" section. It should look something like this



  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test",
    "eject": "react-scripts eject",
    "storybook": "start-storybook -p 9009 -s public",
    "build-storybook": "build-storybook -s public",
    "postinstall": "yarn build"
  },

We can see the start command there. We are going to add a prestart command which will automatically get run whenever you type yarn start. That will create the certificate every time it runs and have it in place for when the webpack dev server starts up.
Add the following line in your scripts section



    "prestart": "@powershell -NoProfile -ExecutionPolicy Unrestricted -Command ./certificates.ps1",

Now run your start command and you should see the messages saying our certificate is being created. After that you shouldn't have any warnings.