Skip to content

Instantly share code, notes, and snippets.

artronics / github-context.json
Created Sep 30, 2022 — forked from colbyfayock/github-context.json
Sample payload for Github Action `github` context
View github-context.json
"token": "[token]",
"job": "notifySlack",
"ref": "refs/pull/4/merge",
"sha": "[shad]",
"repository": "colbyfayock/demo-github-actions",
"repository_owner": "colbyfayock",
"repositoryUrl": "git://",
"run_id": 120667610,
"run_number": "2",
View alacritty.yml
columns: 160
lines: 40
family: Meslo LG M DZ
style: Regular
View tmux.conf
# Set prefix to Ctrl-Space instead of Ctrl-b
unbind C-b
set -g prefix C-a
bind a send-prefix
# See (and comments):
bind -n S-Enter send-keys Escape "[13;2u"
bind -n C-Enter send-keys Escape "[13;5u"
# split panes using | and _
View init.vim
set nocompatible
filetype plugin indent on
syntax on
call plug#begin()
Plug 'doums/darcula'
Plug 'ap/vim-css-color'
Plug 'tpope/vim-commentary'
Plug 'neoclide/coc.nvim', {'branch': 'master', 'do': 'yarn install --frozen-lockfile'}
Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
Plug 'ziglang/zig.vim'
View .tmux.conf
unbind C-b
set -g prefix C-Space
bind Space send-prefix
# split panes using | and _
bind | split-window -h
bind _ split-window -v
unbind '"'
unbind %


Client Credentials

This method of authentication is used to obtain an access token outside the context of a user. With machine-to-machine (M2M) applications, such as CLIs, daemons, or services running on your back-end, the system authenticates and authorizes the app rather than a user. For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow (defined in OAuth 2.0 RFC 6749, section 4.4), in which they pass along their Client ID and their credentials to authenticate themselves and get a token.


Proposed Solution to Mappings

For the sake of making the argument easy to understand, I decided to represent the data as simple maps and assert facts about them based on what we know. If I'm assuming something that I'm not sure about then I marked them, so we can verify or investigate them separately.

For this to work let's forget about MedicationRequest, R3, R4, etc. All we care about is the raw data (like json) and the type after decoding it. For example, a MedicationRequest of STU3 version can be represented as type A. Mixing the actual resource name with its version only makes understanding the problem harder without any contribution to the solution.

Raw data and Profile

Here is an example of an input data:

package com.example.hellodemo;
import org.apache.http.HttpEntity;
import org.apache.http.NameValuePair;
import org.apache.http.client.entity.UrlEncodedFormEntity;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
View errorCode.yaml
type: object
description: Internal error code.
type: array
type: object
readOnly: true
View operationOutcome.yaml
type: object
description: |
Outcome of an operation that does not result in a resource or bundle being returned (e.g. error, async/batch submission).
There are a number of possible error codes that can be returned along with a more detailed description in the `display` field.
There are general outcomes:
| Code | Response Code | Description |
| -------------------------- | ------------- | --------------------------------------------- |
| ACCESS_DENIED | 401 | Used when the user does not have permission for a particular request. e.g. when their ASID does not have the correct interactions attached to it. |