@ory/argus 0.4.0 → 0.5.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,108 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ory-build-integration
|
|
3
|
+
description: Wire an Ory Network integration into your own application using the ory/integrates template patterns. Use when the user wants to add an Ory integration to their app — an Action webhook handler that fires during a flow, a Console/gateway config to validate Ory JWTs, or an Enterprise live-event-stream consumer — phrases like "wire up an Ory webhook", "add an Ory Action handler to my app", "react to Ory identity events", "validate Ory tokens at my gateway", "build an Ory integration in my project". For contributing an integration back to ory/integrates instead, use ory-contribute-integration.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Build an Ory Integration Into Your App
|
|
7
|
+
|
|
8
|
+
You are helping the user wire an Ory Network integration into **their own
|
|
9
|
+
application**, reusing the proven patterns from the public `ory/integrates`
|
|
10
|
+
repository. There is no contribution, registry, `Maintained by:`, or DCO concern
|
|
11
|
+
here — you fetch the **runnable subset** of a template and adapt it in place.
|
|
12
|
+
|
|
13
|
+
This skill carries the workflow. The template files live in
|
|
14
|
+
`github.com/ory/integrates` (branch `main`); fetch the ones you need so they stay
|
|
15
|
+
current.
|
|
16
|
+
|
|
17
|
+
> **Precondition:** `ory/integrates` must be reachable (public repo). If a fetch
|
|
18
|
+
> fails, tell the user and stop — do not fabricate handler code.
|
|
19
|
+
|
|
20
|
+
## Step 1 — Determine the type and app context
|
|
21
|
+
|
|
22
|
+
Pick the integration type from intent; ask directly if unclear.
|
|
23
|
+
|
|
24
|
+
| Signal from the user | Type |
|
|
25
|
+
|---|---|
|
|
26
|
+
| Transform/enrich an identity at registration; gate or react to a flow **synchronously**; call a vendor API during an Ory flow | `webhook` |
|
|
27
|
+
| Validate Ory JWTs at a gateway; **Console-only** config; no handler code | `config` |
|
|
28
|
+
| React to events **asynchronously**; Ory **Enterprise** Live Event Stream consumer | `http-event` |
|
|
29
|
+
|
|
30
|
+
Also establish: the app's framework/runtime, where the handler will live, and how
|
|
31
|
+
it's deployed (these decide where you write files and how you mount the route).
|
|
32
|
+
|
|
33
|
+
## Step 2 — Fetch the runnable subset
|
|
34
|
+
|
|
35
|
+
Pull only the files the user needs from `_examples/_template-<type>/`. Prefer raw
|
|
36
|
+
fetch so you don't clone the whole repo into the user's project.
|
|
37
|
+
|
|
38
|
+
**Raw file fetch** (base URL
|
|
39
|
+
`https://raw.githubusercontent.com/ory/integrates/main/_examples/_template-<type>/`):
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
BASE=https://raw.githubusercontent.com/ory/integrates/main/_examples/_template-webhook
|
|
43
|
+
mkdir -p ory-integration/webhook ory-integration/jsonnet
|
|
44
|
+
curl -fsSL "$BASE/ory-actions.yaml" -o ory-integration/ory-actions.yaml
|
|
45
|
+
curl -fsSL "$BASE/jsonnet/identity.jsonnet" -o ory-integration/jsonnet/identity.jsonnet
|
|
46
|
+
curl -fsSL "$BASE/webhook/server.ts" -o ory-integration/webhook/server.ts
|
|
47
|
+
curl -fsSL "$BASE/webhook/package.json" -o ory-integration/webhook/package.json
|
|
48
|
+
curl -fsSL "$BASE/webhook/tsconfig.json" -o ory-integration/webhook/tsconfig.json
|
|
49
|
+
curl -fsSL "$BASE/webhook/.env.example" -o ory-integration/webhook/.env.example
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
**Sparse checkout** (if the user prefers a git copy to diff against):
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
git clone --depth 1 --filter=blob:none --sparse https://github.com/ory/integrates /tmp/ory-integrates
|
|
56
|
+
git -C /tmp/ory-integrates sparse-checkout set _examples/_template-webhook
|
|
57
|
+
# then copy the files you want out of /tmp/ory-integrates/_examples/_template-webhook
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
Runnable subset per type (skip `registry.entry.yaml.example`, the
|
|
61
|
+
`Maintained by:` README, and lockfiles — `npm install` regenerates the lock):
|
|
62
|
+
|
|
63
|
+
- **webhook** — `ory-actions.yaml`, `jsonnet/identity.jsonnet`,
|
|
64
|
+
`webhook/{server.ts, package.json, tsconfig.json, .env.example}`.
|
|
65
|
+
- **config** — `ory-console-steps.md` (no code; it's a Console walkthrough).
|
|
66
|
+
- **http-event** — `ory-event-stream.yaml`,
|
|
67
|
+
`webhook/{server.ts, idempotency.ts, package.json, tsconfig.json, .env.example}`.
|
|
68
|
+
|
|
69
|
+
Adapt the fetched handler into the user's app: integrate the route into their
|
|
70
|
+
existing server if they have one, or run the `webhook/` server standalone.
|
|
71
|
+
|
|
72
|
+
## Step 3 — Wire it to the user's Ory project
|
|
73
|
+
|
|
74
|
+
- **webhook** — deploy the handler, then create an Ory Action pointing at it using
|
|
75
|
+
`ory-actions.yaml` as the template (set `url` to the deployed handler, set the
|
|
76
|
+
`X-Webhook-Secret` value, and the matching `ORY_WEBHOOK_SECRET` in the
|
|
77
|
+
handler's `.env`). Adjust `jsonnet/identity.jsonnet` to the body shape the
|
|
78
|
+
handler expects. Apply via the Ory Console or the Ory CLI.
|
|
79
|
+
- **config** — follow `ory-console-steps.md`: configure the vendor side, then the
|
|
80
|
+
Ory Console (gateway/JWT validation, provider config, etc.). No code to deploy.
|
|
81
|
+
- **http-event** (Enterprise) — deploy the handler, then configure the
|
|
82
|
+
event-stream target from `ory-event-stream.yaml` (URL with embedded Basic Auth;
|
|
83
|
+
set `BASIC_AUTH_USER` / `BASIC_AUTH_PASSWORD` in `.env` to match) and the event
|
|
84
|
+
filter. Keep the `idempotency.ts` dedupe wired up — delivery is at-least-once.
|
|
85
|
+
|
|
86
|
+
Always verify the signature/secret path: webhook uses the `X-Webhook-Secret`
|
|
87
|
+
header; http-event uses HTTP Basic Auth embedded in the configured URL.
|
|
88
|
+
|
|
89
|
+
## Step 4 — Test locally
|
|
90
|
+
|
|
91
|
+
Stand up Ory and exercise the flow locally before pointing at production:
|
|
92
|
+
|
|
93
|
+
- Use {{REF_LOCAL_DEV}} to run a local Ory stack (Kratos / Keto / Hydra +
|
|
94
|
+
gateway), then trigger the relevant flow and confirm the handler fires.
|
|
95
|
+
- Use {{REF_AUTH_SETUP}} when the app also needs Ory project / SDK setup wired up.
|
|
96
|
+
|
|
97
|
+
For a webhook, hit `GET /health` on the handler, then run the Ory flow and check
|
|
98
|
+
the handler logs. For http-event, emit a test event and confirm both the dedupe
|
|
99
|
+
and the downstream side effect.
|
|
100
|
+
|
|
101
|
+
## What this skill does NOT do
|
|
102
|
+
|
|
103
|
+
- It does not create a contribution to `ory/integrates` (no `registry.entry.yaml`,
|
|
104
|
+
`Maintained by:`, SPDX, or DCO) — use `ory-contribute-integration` for that.
|
|
105
|
+
- It does not invent handler code — it fetches the real templates from
|
|
106
|
+
`ory/integrates`.
|
|
107
|
+
- It does not deploy to the user's infrastructure or modify their Ory project
|
|
108
|
+
without confirmation.
|
|
@@ -0,0 +1,164 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ory-contribute-integration
|
|
3
|
+
description: Author a new Ory Network integration as a contribution to the public ory/integrates repository. Use when the user wants to contribute an integration back to Ory, add an entry to the Ory integrations registry/catalog, open a PR against ory/integrates, or publish a reusable integration for others — phrases like "contribute an Ory integration", "add my integration to ory/integrates", "submit a webhook integration to Ory", "get my integration into the registry". For wiring an integration into your own app instead, use ory-build-integration.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Contribute an Integration to ory/integrates
|
|
7
|
+
|
|
8
|
+
You are helping the user author a new integration and contribute it back to the
|
|
9
|
+
public `ory/integrates` repository ("Sample code and reference configuration for
|
|
10
|
+
integrating Ory Network with third-party products"). The deliverable is a pull
|
|
11
|
+
request against `github.com/ory/integrates`.
|
|
12
|
+
|
|
13
|
+
This skill carries the workflow. The **template files** live in the repo itself —
|
|
14
|
+
fetch them from `github.com/ory/integrates` (branch `main`) rather than
|
|
15
|
+
reproducing them, so they never drift.
|
|
16
|
+
|
|
17
|
+
> **Precondition:** `ory/integrates` must be reachable (it is a public repo). If
|
|
18
|
+
> `gh repo view ory/integrates` or a fetch of a template file fails, tell the
|
|
19
|
+
> user the repo is unreachable and stop — do not fabricate template contents.
|
|
20
|
+
|
|
21
|
+
## Step 0 — Open the "New integration" issue first
|
|
22
|
+
|
|
23
|
+
Ory asks contributors to open a **New integration** issue before the PR, so scope
|
|
24
|
+
is confirmed and the work isn't already in flight. Remind the user to do this
|
|
25
|
+
(GitHub → `ory/integrates` → Issues → "New integration" template) and capture the
|
|
26
|
+
issue number for the PR.
|
|
27
|
+
|
|
28
|
+
## Step 1 — Get a checkout and pick the category
|
|
29
|
+
|
|
30
|
+
The contribution workflow happens inside a checkout of the repo:
|
|
31
|
+
|
|
32
|
+
```bash
|
|
33
|
+
gh repo clone ory/integrates
|
|
34
|
+
cd integrates
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
(or a fork, if the user will PR from their own remote.) Then choose the
|
|
38
|
+
**category folder** the integration belongs in — it must match an existing
|
|
39
|
+
top-level directory (`crm/`, `api-gateways/`, `identity-verification/`, `mfa/`,
|
|
40
|
+
`enterprise-sso/`, …). List them with `ls -d */ | grep -v _examples`.
|
|
41
|
+
|
|
42
|
+
## Step 2 — Determine the integration type
|
|
43
|
+
|
|
44
|
+
Every integration is one of three types. Infer from intent; if unclear, ask
|
|
45
|
+
directly.
|
|
46
|
+
|
|
47
|
+
| Signal from the user | Type | Template |
|
|
48
|
+
|---|---|---|
|
|
49
|
+
| Transform/enrich an identity at registration; gate or react to a self-service flow **synchronously**; call a vendor API during an Ory flow | `webhook` | `_examples/_template-webhook/` |
|
|
50
|
+
| Validate Ory JWTs at a gateway; **Console-only** setup; no handler code | `config` | `_examples/_template-config/` |
|
|
51
|
+
| React to events **asynchronously**; Ory Network **Enterprise** Live Event Stream consumer | `http-event` | `_examples/_template-http-event/` |
|
|
52
|
+
|
|
53
|
+
## Step 3 — Copy the template into the category folder
|
|
54
|
+
|
|
55
|
+
From the repo root, copy the whole template directory to
|
|
56
|
+
`<category>/<integration-slug>` (slug is lowercase, hyphenated, matches the dir
|
|
57
|
+
name):
|
|
58
|
+
|
|
59
|
+
```bash
|
|
60
|
+
cp -R _examples/_template-webhook crm/<integration-slug> # webhook
|
|
61
|
+
# or _examples/_template-config / _examples/_template-http-event
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
Each template ships these files (confirm with `ls -R <category>/<integration-slug>`):
|
|
65
|
+
|
|
66
|
+
- **webhook** — `README.md`, `ory-actions.yaml`, `jsonnet/identity.jsonnet`,
|
|
67
|
+
`registry.entry.yaml.example`, and a runnable `webhook/` (`server.ts`,
|
|
68
|
+
`package.json`, `package-lock.json`, `tsconfig.json`, `.env.example`).
|
|
69
|
+
- **config** — `README.md`, `ory-console-steps.md`,
|
|
70
|
+
`registry.entry.yaml.example`.
|
|
71
|
+
- **http-event** — `README.md`, `ory-event-stream.yaml`,
|
|
72
|
+
`registry.entry.yaml.example`, and a runnable `webhook/` (`server.ts`,
|
|
73
|
+
`idempotency.ts`, `package.json`, `package-lock.json`, `tsconfig.json`,
|
|
74
|
+
`.env.example`).
|
|
75
|
+
|
|
76
|
+
The copied files are the source of truth — read them and fill in every
|
|
77
|
+
`<placeholder>` and `<!-- comment -->`.
|
|
78
|
+
|
|
79
|
+
## Step 4 — Fill out the integration
|
|
80
|
+
|
|
81
|
+
1. **README.md** — replace `<Integration Name>`, set the `Maintained by:` line
|
|
82
|
+
(`Ory Engineering`, `Community contributors`, or the user's `@handle`), and
|
|
83
|
+
complete: what it does, use case, prerequisites, deploy steps, **Ory Console
|
|
84
|
+
configuration**, troubleshooting. No vendor marketing — factual wiring only.
|
|
85
|
+
2. **Code / config for the type** (see per-type notes below).
|
|
86
|
+
3. **registry.entry.yaml** — rename `registry.entry.yaml.example` →
|
|
87
|
+
`registry.entry.yaml` and fill in every field (`name`, `displayName`,
|
|
88
|
+
`vendor`, `category`, `type`, `maintainedBy`, `description`, `useCase`,
|
|
89
|
+
`coreFunctionality`, `oryMechanism`, `protocol`, `status`; http-event also
|
|
90
|
+
needs `subscribedEvents`). The field comments in the file enumerate the
|
|
91
|
+
allowed enum values.
|
|
92
|
+
4. **Apache-2.0 SPDX header** at the top of every source file you ship, e.g.
|
|
93
|
+
`// SPDX-License-Identifier: Apache-2.0`.
|
|
94
|
+
|
|
95
|
+
### webhook specifics
|
|
96
|
+
- `ory-actions.yaml` is the Ory Action hook config (a `web_hook` with an
|
|
97
|
+
`X-Webhook-Secret` `api_key` auth header). Point `url` at the deployed handler
|
|
98
|
+
and set the shared secret.
|
|
99
|
+
- `jsonnet/identity.jsonnet` is the request-body template — adjust to the shape
|
|
100
|
+
your handler expects.
|
|
101
|
+
- The `webhook/` server must run (`cd webhook && cp .env.example .env && npm
|
|
102
|
+
install && npm start`); it exposes `GET /health` and the `POST` target.
|
|
103
|
+
`ORY_WEBHOOK_SECRET` in `.env` must match the secret in `ory-actions.yaml`.
|
|
104
|
+
|
|
105
|
+
### config specifics
|
|
106
|
+
- No code. Write a real `ory-console-steps.md`: vendor-side setup, the exact Ory
|
|
107
|
+
Console navigation, the fields to configure, a test, and troubleshooting. A
|
|
108
|
+
README-only contribution with no real console steps will be rejected.
|
|
109
|
+
|
|
110
|
+
### http-event specifics
|
|
111
|
+
- `ory-event-stream.yaml` configures the Ory-side event target (URL with embedded
|
|
112
|
+
Basic Auth) and the event filter. List the consumed events under both the YAML
|
|
113
|
+
`events:` and the registry `subscribedEvents:`.
|
|
114
|
+
- The `webhook/` handler authenticates with HTTP Basic Auth, dedupes by SHA-256
|
|
115
|
+
of the body (`idempotency.ts`) because delivery is at-least-once, and always
|
|
116
|
+
returns 200. Live event streams are an **Enterprise** feature — say so in the
|
|
117
|
+
README.
|
|
118
|
+
|
|
119
|
+
## Step 5 — Regenerate the registry
|
|
120
|
+
|
|
121
|
+
From the repo root:
|
|
122
|
+
|
|
123
|
+
```bash
|
|
124
|
+
cd scripts && npm install && cd ..
|
|
125
|
+
node scripts/build-registry.js
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
This rewrites the top-level `registry.yaml` from every `registry.entry.yaml`.
|
|
129
|
+
Commit the regenerated `registry.yaml` along with your integration.
|
|
130
|
+
|
|
131
|
+
## Step 6 — Open the PR (DCO + checklist)
|
|
132
|
+
|
|
133
|
+
Walk the CONTRIBUTING checklist before opening the PR:
|
|
134
|
+
|
|
135
|
+
- [ ] Integration is in the correct category folder.
|
|
136
|
+
- [ ] `README.md` covers what it does, prerequisites, deploy, Console config,
|
|
137
|
+
troubleshooting, and a `Maintained by:` line.
|
|
138
|
+
- [ ] Type deliverables present: webhook → `ory-actions.yaml` + `jsonnet/` +
|
|
139
|
+
runnable `webhook/`; config → real `ory-console-steps.md`; http-event →
|
|
140
|
+
`ory-event-stream.yaml` + runnable `webhook/` + `subscribedEvents`.
|
|
141
|
+
- [ ] `registry.entry.yaml` filled and `registry.yaml` regenerated.
|
|
142
|
+
- [ ] Apache-2.0 SPDX header in each source file.
|
|
143
|
+
- [ ] **DCO sign-off on every commit** — `git commit -s`.
|
|
144
|
+
|
|
145
|
+
```bash
|
|
146
|
+
git checkout -b add-<integration-slug>-integration
|
|
147
|
+
git add <category>/<integration-slug> registry.yaml
|
|
148
|
+
git commit -s -m "Add <Integration Name> integration"
|
|
149
|
+
git push -u origin add-<integration-slug>-integration
|
|
150
|
+
gh pr create --repo ory/integrates --title "Add <Integration Name> integration" \
|
|
151
|
+
--body "Closes #<issue-number>. <summary>"
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
Expect review questions about Ory Network compatibility, webhook security
|
|
155
|
+
(signature verification, secret handling), and README clarity.
|
|
156
|
+
|
|
157
|
+
## What this skill does NOT do
|
|
158
|
+
|
|
159
|
+
- It does not wire an integration into the user's own application — use
|
|
160
|
+
`ory-build-integration` for that (no registry/DCO).
|
|
161
|
+
- It does not run `build-registry.js` or open the PR without confirmation; it
|
|
162
|
+
guides, the user executes.
|
|
163
|
+
- It does not invent template contents — it reads the real files from
|
|
164
|
+
`ory/integrates`.
|
package/dist/skills.d.ts
CHANGED
|
@@ -1,7 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* Canonical Ory agent skills and commands.
|
|
3
3
|
*
|
|
4
|
-
* The skill playbooks (auth-setup, login-flow, social-login, local-dev
|
|
4
|
+
* The skill playbooks (auth-setup, login-flow, social-login, local-dev,
|
|
5
|
+
* permissions-onboarding, contribute-integration, build-integration) and the
|
|
5
6
|
* local-stack commands (local-up, local-down) live once, as token-bearing
|
|
6
7
|
* templates under `packages/core/assets/`. Every harness plugin renders them
|
|
7
8
|
* through {@link renderOrySkills} / {@link renderOryCommands}, substituting the
|
|
@@ -50,7 +51,7 @@ export interface RenderProfileOptions {
|
|
|
50
51
|
packageName: string;
|
|
51
52
|
}
|
|
52
53
|
/**
|
|
53
|
-
* Render the
|
|
54
|
+
* Render the guide skills for a harness as `SKILL.md` documents.
|
|
54
55
|
*/
|
|
55
56
|
export declare function renderOrySkills(harness: string, opts: RenderProfileOptions): RenderedSkill[];
|
|
56
57
|
/**
|
package/dist/skills.js
CHANGED
|
@@ -2,7 +2,8 @@
|
|
|
2
2
|
/**
|
|
3
3
|
* Canonical Ory agent skills and commands.
|
|
4
4
|
*
|
|
5
|
-
* The skill playbooks (auth-setup, login-flow, social-login, local-dev
|
|
5
|
+
* The skill playbooks (auth-setup, login-flow, social-login, local-dev,
|
|
6
|
+
* permissions-onboarding, contribute-integration, build-integration) and the
|
|
6
7
|
* local-stack commands (local-up, local-down) live once, as token-bearing
|
|
7
8
|
* templates under `packages/core/assets/`. Every harness plugin renders them
|
|
8
9
|
* through {@link renderOrySkills} / {@link renderOryCommands}, substituting the
|
|
@@ -70,6 +71,16 @@ const SKILL_SOURCES = [
|
|
|
70
71
|
name: "ory-permissions-onboarding",
|
|
71
72
|
file: "skills/permissions-onboarding/SKILL.md",
|
|
72
73
|
},
|
|
74
|
+
{
|
|
75
|
+
id: "contribute-integration",
|
|
76
|
+
name: "ory-contribute-integration",
|
|
77
|
+
file: "skills/ory-contribute-integration/SKILL.md",
|
|
78
|
+
},
|
|
79
|
+
{
|
|
80
|
+
id: "build-integration",
|
|
81
|
+
name: "ory-build-integration",
|
|
82
|
+
file: "skills/ory-build-integration/SKILL.md",
|
|
83
|
+
},
|
|
73
84
|
];
|
|
74
85
|
const COMMAND_SOURCES = [
|
|
75
86
|
{
|
|
@@ -177,7 +188,7 @@ function parseFrontmatter(markdown) {
|
|
|
177
188
|
}
|
|
178
189
|
// ─── Public render API ──────────────────────────────────────────────
|
|
179
190
|
/**
|
|
180
|
-
* Render the
|
|
191
|
+
* Render the guide skills for a harness as `SKILL.md` documents.
|
|
181
192
|
*/
|
|
182
193
|
function renderOrySkills(harness, opts) {
|
|
183
194
|
const profile = buildProfile(harness, opts);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ory/argus",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.5.0",
|
|
4
4
|
"description": "Ory Argus: the core API for building authentication, authorization, and audit into AI agent harness plugins, extensions, and custom integrations",
|
|
5
5
|
"license": "Apache-2.0",
|
|
6
6
|
"homepage": "https://ory.com",
|