Skip to content

Commit bb162e6

Browse files
authored
Merge pull request #32 from ikalnytskyi/feat/auth-store
HTTPie Auth Store
2 parents 56bd7f9 + b7d6b47 commit bb162e6

File tree

18 files changed

+1599
-1576
lines changed

18 files changed

+1599
-1576
lines changed

.github/workflows/ci.yml

Lines changed: 6 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,9 @@ jobs:
1919
python-version: "3.12"
2020

2121
- name: Run ruff
22-
run: pipx run tox -e lint
22+
run: |
23+
python3 -m pip install tox
24+
python3 -m tox -e lint
2325
env:
2426
RUFF_OUTPUT_FORMAT: github
2527

@@ -53,4 +55,6 @@ jobs:
5355
if: matrix.os == 'macos-latest'
5456

5557
- name: Run pytest
56-
run: pipx run tox -e test
58+
run: |
59+
python3 -m pip install tox
60+
python3 -m tox -e test

README.md

Lines changed: 333 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,333 @@
1+
# HTTPie Auth Store
2+
3+
> [!NOTE]
4+
>
5+
> The plugin was renamed from `httpie-credential-store` to `httpie-auth-store`
6+
> primarily due to backward incompatible changes and because the new name
7+
> better reflects its nature.
8+
9+
HTTPie Auth Store is an [HTTPie] authentication plugin that automatically
10+
selects the appropriate authentication type and payload from a file containing
11+
authentication bindings, then uses them for the current request. No more
12+
memorizing or searching for tokens, usernames, or passwords — simply add them
13+
to the authentication store, and the plugin handles the rest. This plugin also
14+
supports various secret storage options, such as system keychains and password
15+
managers (see supported [Secret providers]).
16+
17+
Eager to get started? Just start with installing!
18+
19+
```sh
20+
httpie cli plugins install httpie-auth-store
21+
```
22+
23+
or via `pip` in the same python environment where HTTPie is installed:
24+
25+
```sh
26+
python3 -m pip install httpie-auth-store
27+
```
28+
29+
30+
## Table of Content
31+
32+
* [Usage](#usage)
33+
* [Authentication types](#authentication-types)
34+
* [basic](#basic)
35+
* [digest](#digest)
36+
* [bearer](#bearer)
37+
* [header](#header)
38+
* [composite](#composite)
39+
* [hmac](#hmac)
40+
* [Secret providers](#secret-providers)
41+
* [sh](#sh)
42+
* [system](#system)
43+
* [password-store](#password-store)
44+
* [FAQ](#faq)
45+
46+
47+
## Usage
48+
49+
> [!IMPORTANT]
50+
>
51+
> Do not forget to pass `-A store` or `--auth-type store` to HTTPie in order to
52+
> activate the plugin.
53+
54+
Once installed, the plugin looks for `auth_store.json` located in the HTTPie
55+
configuration directory. On macOS and Linux, it tries the following locations:
56+
`$HTTPIE_CONFIG_DIR/auth_store.json`, `$HOME/.httpie/auth_store.json` and
57+
`$XDG_CONFIG_HOME/httpie/auth_store.json`; on Windows —
58+
`%HTTPIE_CONFIG_DIR%\auth_store.json` and `%APPDATA%\httpie\auth_store.json`
59+
60+
> [!NOTE]
61+
>
62+
> The authentication store can be automatically created with few examples
63+
> inside on first plugin activation, e.g. `http -A store https://pie.dev`.
64+
65+
The authentication store is a JSON file that contains two sections: `bindings`
66+
and `secrets`:
67+
68+
```json
69+
{
70+
"bindings": [
71+
{
72+
"auth_type": "bearer",
73+
"auth": "$GITHUB_TOKEN",
74+
"resources": ["https://api.github.com/"]
75+
},
76+
{
77+
"id": "bots",
78+
"auth_type": "bearer",
79+
"auth": "ZWFzdGVyIGVnZwo",
80+
"resources": ["https://api.github.com/"]
81+
},
82+
],
83+
"secrets": {
84+
"GITHUB_TOKEN": {
85+
"provider": "system",
86+
"service": "github.com",
87+
"username": "ikalnytskyi"
88+
}
89+
}
90+
}
91+
```
92+
93+
Each _binding_ is a JSON object that contains the following keys:
94+
95+
* `id` (*str*, *optional*) is an authentication binding ID that can be used to
96+
overcome ambiguity when two or more bindings are matched.
97+
98+
* `auth_type` (*str*, *required*) is an authentication type supported by HTTPie,
99+
either natively or via third-party plugins. See [Authentication types] for
100+
details.
101+
102+
* `auth` (*str*, *optional*) is an authentication payload for the given
103+
authentication type. Required for certain authentication types, optional for
104+
others. Tokens started with `$` are replaced with secrets referred by those
105+
tokens. The `$` sign must be escaped (`$$`) to remain untouched.
106+
107+
* `resources` (*List\[str\]*, *required*) is an array of URLs to activate this
108+
binding for. Must contain both scheme and hostname.
109+
110+
Each _secret_ is a KV-pair, where key is a secret name, and value is either a
111+
secret itself or a JSON object that specified how a secret must be retrieved
112+
from secure storage. The JSON object must contain the `provider` key. Presence
113+
of other keys are provider dependent (see [Secret providers] section below).
114+
115+
Once the authenticate store is set up, just pass `-A store` to HTTPie to
116+
activate the plugin and perform some magic for you.
117+
118+
```sh
119+
http -A store https://api.github.com
120+
```
121+
122+
If there are two or more authentication bingind in the store that match the
123+
same resource, you can select appropriate binding by providing a binding ID by
124+
passing `-a` or `--auth` to HTTPie. This might come handy when you have
125+
multiple accounts on the same web resource.
126+
127+
```sh
128+
http -A store -a bots https://api.github.com
129+
```
130+
131+
132+
## Authentication types
133+
134+
HTTPie Auth Store supports both built-in and third-party HTTPie authentication
135+
types as well as provides few authentication types on its own.
136+
137+
> [!TIP]
138+
>
139+
> It's advised to store your secrets in password managers instead of storing
140+
> them directly in the authentication store file.
141+
142+
### basic
143+
144+
The 'Basic' HTTP authentication type as defined in RFC 7617. Transmits
145+
credentials as username/password pairs, encoded using Base64.
146+
147+
```json
148+
{
149+
"auth_type": "basic",
150+
"auth": "ihor:p@ss"
151+
}
152+
```
153+
154+
where
155+
156+
* `auth` is a `:`-delimited username/password pair
157+
158+
### digest
159+
160+
The 'Digest' HTTP authentication type as defined in RFC 2617. It applies a hash
161+
function to the username and password before sending them over the network.
162+
163+
164+
```json
165+
{
166+
"auth_type": "digest",
167+
"auth": "ihor:p@ss"
168+
}
169+
```
170+
171+
where
172+
173+
* `auth` is a `:`-delimited username/password pair
174+
175+
### bearer
176+
177+
The 'Bearer' HTTP authentication type transmits token in the `Authorization`
178+
HTTP header.
179+
180+
```json
181+
{
182+
"auth_type": "bearer",
183+
"auth": "t0ken"
184+
}
185+
```
186+
187+
where
188+
189+
* `auth` is a bearer token to authenticate with
190+
191+
### header
192+
193+
The 'Header' authentication type is not exactly an authentication scheme. It's
194+
rather a way to set a free-formed HTTP header that may or may not contain any
195+
secret material.
196+
197+
```json
198+
{
199+
"auth_type": "header",
200+
"auth": "X-Secret:s3cret"
201+
}
202+
```
203+
204+
where
205+
206+
* `auth` is a `:`-delimited HTTP header name/value pair
207+
208+
The 'Header' authentication type can be used to bypass any kind of limitations
209+
imposed by built-in or third-party authentication types. For instance, you can
210+
pass a bearer token with non-default authentication scheme, say `JWT`, without
211+
breaking a sweat.
212+
213+
```json
214+
{
215+
"auth_type": "header",
216+
"auth": "Authorization:JWT t0ken"
217+
}
218+
```
219+
220+
### composite
221+
222+
The 'Composite' authentication type is a not an authentication type either.
223+
It's a way to use multiple authentication types simultaneously. It might come
224+
handy when in addition to `basic` or `bearer` authentication, you have to
225+
supply an extra secret via custom HTTP header.
226+
227+
```json
228+
{
229+
"auth_type": "composite",
230+
"auth": [
231+
{
232+
"auth_type": "bearer",
233+
"auth": "t0ken"
234+
},
235+
{
236+
"auth_type": "header",
237+
"auth": "X-Secret:s3cret"
238+
}
239+
]
240+
}
241+
```
242+
243+
where
244+
245+
* `auth` is a list of authentication entries, as supported by HTTPie
246+
247+
### hmac
248+
249+
The 'HMAC' authentication type is not built-in and requires the `httpie-hmac`
250+
plugin to be installed first. Its only purpose here is to serve as an example
251+
of how to use a third-party authentication type in the authentication store.
252+
253+
```json
254+
{
255+
"auth_type": "hmac",
256+
"auth": "secret:czNjcjN0Cg=="
257+
}
258+
```
259+
260+
where
261+
262+
* `auth` is a HMAC specific authentication payload
263+
264+
265+
## Secret providers
266+
267+
The plugin supports some secret providers that can be used to retrieve tokens,
268+
passwords and other secret materials from various secured storages.
269+
270+
### sh
271+
272+
The 'Sh' secret provider retrieves a secret from the standard output of the
273+
shell script. This is a universal approach that can be used to retrieve secrets
274+
from unsupported password managers using their command line interfaces.
275+
276+
```json
277+
{
278+
"provider": "sh",
279+
"script": "cat ~/path/to/secret | tr -d '\n'"
280+
}
281+
```
282+
283+
where
284+
285+
* `script` is a shell script to execute
286+
287+
### system
288+
289+
The 'System' secret provider, as the name suggests, retrieves a secret from
290+
your system keychain. It may be KWallet, GNOME Keyring, macOS Keychain or even
291+
Windows Credential Locker.
292+
293+
```json
294+
{
295+
"provider": "system",
296+
"service": "github",
297+
"username": "ikalnytskyi"
298+
}
299+
```
300+
301+
where
302+
303+
* `service` is a service to retrieve a secret from
304+
* `username` is a username to retrieve a secret from
305+
306+
### password-store
307+
308+
The 'Password Store' secret provider invokes the `pass` executable on your
309+
system, and retrieves the secret from the first line of referred record.
310+
311+
```json
312+
{
313+
"provider": "password-store",
314+
"name": "github.com/ikalnytskyi"
315+
}
316+
```
317+
318+
where
319+
320+
* `name` is a password-store entry name to retrieve a secret from
321+
322+
## FAQ
323+
324+
* **Q**: How to get know what authentication is used for the given request?
325+
326+
**A**: You can run HTTPie with `--offline` argument to print the request
327+
header along with injected authentication credentials.
328+
329+
330+
[HTTPie]: https://httpie.org/
331+
[Authentication types]: #authentication-types
332+
[Secret providers]: #secret-providers
333+
[password-store]: https://www.passwordstore.org/

0 commit comments

Comments
 (0)