Table of Contents

Why Cache Access Token with MSAL?

Building upon the previous post that performs delegated access authentication with MSAL, suppose your program uses this function to get the access token.

def get_access_token():
    app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
    result = app.acquire_token_interactive(scopes=SCOPES)
    access_token = result['access_token']

    return access_token

In this case, it will always launch the browser to complete the authentication flow and retrieve the access token every time the program runs.

While it works, it introduces a slight latency to your program. Fortunately, MSAL provides the capability to cache the access token.

Solution A: Use custom persistence cache

In this solution, we can introduce our custom persistence cache.

First, we can use these functions to load the access token from the cache file and save it to the cache file.

import os
import msal

...
CACHE_FILE = 'msal_token_cache.json'

def load_cache():
    cache = msal.SerializableTokenCache()

    if os.path.exists(CACHE_FILE):
        with open(CACHE_FILE, 'rb') as f:
            cache.deserialize(f.read())

    return cache

def save_cache(cache):
    if cache.has_state_changed:
        with open(CACHE_FILE, 'wb') as f:
            f.write(cache.serialize().encode())

We can first attempt to get a valid access token from the cache. It will only get the token interactively via the browser if the access token doesn’t exist or has expired.

def get_access_token():
    cache = load_cache()
    app = msal.PublicClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        token_cache=cache,
    )
    result = None
    accounts = app.get_accounts()

    if accounts:
        result = app.acquire_token_silent(SCOPES, account=accounts[0])

    if not result:
        result = app.acquire_token_interactive(scopes=SCOPES)

    save_cache(cache)
    access_token = result['access_token']

    return access_token

While this solution works, the implementation code is very lengthy. Furthermore, the access token is stored in the cache file as clear text.

Solution B: Use the OS platform’s encrypted vault (PREFERRED)

A Python package called msal-extensions allows the access token to be stored securely in the OS platform’s encrypted vault. For example, If the program runs on MacOS, KeyChain will be used. Windows uses DPAPI, and Linux uses LibSecret.

To begin, install that Python package.

# requirements.txt

msal
msal-extensions

The configuration is much simpler than Solution A.

import msal
from msal_extensions import build_encrypted_persistence, PersistedTokenCache

...
CACHE_FILE = 'msal_token_cache.json'

def get_access_token():
    app = msal.PublicClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        token_cache=PersistedTokenCache(build_encrypted_persistence(CACHE_FILE)),
    )

    result = None
    accounts = app.get_accounts()

    if accounts:
        result = app.acquire_token_silent(SCOPES, account=accounts[0])

    if not result:
        result = app.acquire_token_interactive(scopes=SCOPES)

    access_token = result['access_token']

    return access_token

When running the program on MacOS, the access token is stored in the KeyChain.

Note: An empty cache file named msal_token_cache.json has also been created. Unfortunately, there is no option in msal-extensions==1.2.0 to disable the creation of this file at the moment.

The post MSAL: Caching Access Token appeared first on My Shitty Code.

Table of Contents

Why Launch a Specific Browser with MSAL?

Building upon the previous post that performs delegated access authentication with MSAL, your institution may sometimes allow you to access Microsoft 365 products only on the approved browsers.

By default, MSAL launches the default browser on your machine to obtain the access token interactively.

If your institution only allows Chrome and your default browser is Firefox, you will get the following message:

Overriding with BROWSER environment variable

MSAL relies on Python’s built-in module called webbrowser to launch the browser. This allows us to change the browser by setting the BROWSER environment variable to the predefined values (‘firefox’, ‘chrome’, etc.)

For example, to launch Firefox instead of the default browser, we can do this:

import os
import msal

# ... 
os.environ['BROWSER'] = 'firefox'
app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
result = app.acquire_token_interactive(scopes=SCOPES)

What if the BROWSER environment variable’s predefined value doesn’t work?

I discovered that Python’s webbrowser failed to launch the correct browser, especially when dealing with Chromnium-based browsers.

For example, suppose my default browser is Brave, and I set the BROWSER environment variable to Chrome. In that case, it will still launch the Brave browser.

# default browser = Brave

os.environ['BROWSER'] = 'chrome'  # doesn't work
app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
result = app.acquire_token_interactive(scopes=SCOPES)

Fortunately, it is possible to specify a full path ending with ‘%s’ instead:

# default browser = Brave

os.environ['BROWSER'] = 'open -a /Applications/Google\\ Chrome.app %s'  # works
app = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY)
result = app.acquire_token_interactive(scopes=SCOPES)

If you are stuck on the “Approve sign in request” or “Set up your device to get access” screen indefinitely, consider clearing the browser cache and then try again.

The post MSAL: Launching Specific Browser with Delegated Access Authentication appeared first on My Shitty Code.

Since upgrading to macOS Ventura, managing custom startup/shutdown schedules directly from the GUI (via Energy Saver) is no longer possible.

SOLUTION

While this feature is not accessible from the GUI anymore, it can still be accomplished using pmset command.

To list all the existing schedules:

pmset -g sched

By default, it is empty.

To schedule a daily shutdown at 11 PM:

sudo pmset repeat shutdown MTWRFSU 23:00:00

While you can achieve a similar outcome by creating a cron job with shutdown -h now, you can pull off various power management actions using pmset, such as shutting down the machine when the UPS emergency is reached or control when the disk/screen should wake up or sleep.

To configure the machine to shut down at 11 PM daily and power on at 1 AM Sunday:

sudo pmset repeat shutdown MTWRFSU 23:00:00 wakeorpoweron S 1:00:00

To show the new schedules:

> pmset -g sched                                                                                                
Repeating power events:
  wakepoweron at 1:00AM Saturday
  shutdown at 11:00PM every day

If you are as forgetful as me, the above command ensures the machine doesn’t run constantly, and it wakes up at 1 AM every Sunday to perform the Time Machine backup to another server.

To learn more, view pmset manual.

The post Mac: Managing Startup/Shutdown Schedules on macOS Ventura appeared first on My Shitty Code.

PROBLEM

When trying to map multiple subdomains (ex: a.localhost, b.localhost, c.localhost, d.localhost) to the same IP, it is not possible to do the following in /etc/hosts:

# /etc/hosts

1.2.3.4 *.localhost

Rather, each subdomain has to be explicitly defined:

# /etc/hosts

1.2.3.4 a.localhost b.localhost c.localhost d.localhost

It requires you to babysit and manage these wildcard subdomains over time, but you do have a good job security.

SOLUTION

Configuration

Install a DNS forwarder using Homebrew.

brew install dnsmasq

Create a configuration to map the wildcard subdomains to the same IP.

sudo bash -c \
  'echo "address=/localhost/1.2.3.4" > /usr/local/etc/dnsmasq.d/localhost.conf'

Restart the service.

sudo brew services restart dnsmasq

Create /etc/resolver directory.

sudo mkdir -p /etc/resolver

Create a custom DNS resolver where the file name is the domain name.

sudo bash -c \
  'echo "nameserver 127.0.0.1" > /etc/resolver/localhost'

Verification

Flush the DNS cache first.

sudo killall -HUP mDNSResponder

Verify that ping command on each subdomain resolves to the correct IP.

$ ping -c 1 a.localhost
PING a.localhost (1.2.3.4): 56 data bytes

$ ping -c 1 b.localhost
PING b.localhost (1.2.3.4): 56 data bytes

$ ping -c 1 a.b.c.localhost
PING a.b.c.localhost (1.2.3.4): 56 data bytes

The post Wildcard Subdomains in /etc/hosts appeared first on My Shitty Code.

You want to access a GUI-based software that is installed in a GCE instance without using NoMachine.

SOLUTION

GCE Instance (One Time Configuration)

Ensure X11Forwarding is enabled and set to yes. If not, change it.

grep X11Forwarding /etc/ssh/sshd_config

If a change is made to this file, restart the service.

sudo systemctl restart sshd

Mac (One Time Configuration)

Apple no longer include X11 since OS X 10.8 Mountain Lion. So, you need to install XQuartz, which is an open source version of X.

Using Homebrew, install XQuartz.

brew install xquartz

Reboot the machine. If you don’t reboot, it will not work.

Once rebooted, add the following line to ~/.ssh/config. If this file does not exist, create it.

ForwardX11 yes

This configuration prevents us from explicitly passing the -X option to the SSH command.

Accessing GUI-based software from Mac

Log into GCP.

gcloud auth login

SSH into the GCE instance.

gcloud compute ssh [INSTANCE] --project [PROJECT] --zone [ZONE]

Once you are in the GCE instance, run any GUI-based software from the command line.

The post GCP: Accessing GUI-Based App in GCE from Mac using X11 appeared first on My Shitty Code.