dazzer-connect 0.1.1 → 0.2.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.
Files changed (3) hide show
  1. package/README.md +7 -2
  2. package/dist/index.js +1512 -391
  3. package/package.json +7 -7
package/README.md CHANGED
@@ -71,17 +71,19 @@ Merge either one with any `mcpServers` entries you already have, save, and resta
71
71
 
72
72
  ```bash
73
73
  dazzer auth status # is my sign-in still good?
74
- dazzer auth logout # sign out and delete what is stored
74
+ dazzer auth logout # cancel your sign-in and remove it from this machine
75
75
  dazzer --help
76
76
  ```
77
77
 
78
78
  `auth status` asks the server rather than trusting what is on disk, so it can tell you your sign-in has been revoked elsewhere.
79
79
 
80
+ `auth logout` cancels your sign-in at the server and removes it from this machine, and says "Signed out." only when it knows both happened. If your sign-in could not be cancelled right now — the server did not answer, or your credential store would not open or would not let it go — it says so, fails, and keeps it, so running it again can finish. If the server gives an answer that will not change, it removes the sign-in from this machine and tells you it stops working once it goes 30 days unused. A pass you pasted into another app keeps working until it expires, within the hour.
81
+
80
82
  ## Where your sign-in is kept
81
83
 
82
84
  Your passes go in your operating system's own credential store — Keychain on macOS, Credential Manager on Windows, Secret Service on Linux. Nothing is written in plain text. The rest, such as which server you signed in to and when it expires, sits in a settings folder alongside your other applications' settings.
83
85
 
84
- Plenty of servers and containers have no credential store at all. Sign-in still completes and prints the blocks above, and `auth status` tells you that is what happened rather than claiming you are signed out.
86
+ Plenty of servers and containers have no credential store at all. Sign-in still completes and prints the blocks above, and `auth status` tells you that is what happened rather than claiming you are signed out. On such a machine `auth logout` cannot check for a saved sign-in, so it will not call itself a sign-out; on Linux, `dazzer auth logout --forget-this-machine` removes this machine's record instead, says that nothing was cancelled, and leaves any sign-in still in the credential store where it is. It refuses on macOS and Windows, whose credential store is locked rather than missing, and when sign-in recorded saving a sign-in here.
85
87
 
86
88
  ## Settings
87
89
 
@@ -92,6 +94,9 @@ Everything points at production unless you say otherwise.
92
94
  | `DAZZER_AUTH_ISSUER` | where you sign in | `https://auth.dazzer.io` |
93
95
  | `DAZZER_AUTH_CLIENT_ID` | which client is asking | `dazzer-cli-local` |
94
96
  | `DAZZER_AUTH_RESOURCE` | what you are signing in to | `https://graph.dazzer.io/mcp` |
97
+ | `DAZZER_API_BASE_URL` | where Dazzer itself is | `https://graph.dazzer.io` |
98
+
99
+ The first three are about signing in. The last one is Dazzer itself — the same service, seen from the other side — and it is the address the tool sends to once it has a sign-in to carry. Both addresses have to be `https`; an unencrypted one is refused before anything is sent.
95
100
 
96
101
  Signing in and checking status each take a matching flag — `--issuer`, `--client-id`, `--resource` — which wins over the setting. Against a sign-in server running on your own machine:
97
102