assinafy 1.5.2 → 1.6.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.
- checksums.yaml +4 -4
- data/CHANGELOG.md +52 -0
- data/README.en.md +815 -0
- data/README.md +608 -480
- data/docs/API_REFERENCE.md +64 -7
- data/lib/assinafy/client.rb +15 -2
- data/lib/assinafy/errors.rb +56 -0
- data/lib/assinafy/oauth.rb +245 -0
- data/lib/assinafy/resources/account_resource.rb +5 -5
- data/lib/assinafy/resources/assignment_resource.rb +62 -7
- data/lib/assinafy/resources/document_resource.rb +9 -9
- data/lib/assinafy/resources/oauth_resource.rb +370 -0
- data/lib/assinafy/resources/user_resource.rb +5 -5
- data/lib/assinafy/version.rb +1 -1
- data/lib/assinafy.rb +2 -0
- data/sig/assinafy.rbs +70 -0
- metadata +7 -18
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: e552b1b827ecb77d5f39f9b6eb64e99e3172173535ef3889a42ae6e17b2c6f9b
|
|
4
|
+
data.tar.gz: c5ffe52ec11ba92dcc11544149d233bcb925f71881ea3df20f267fff15980886
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: cd67d2ab9e3eddec23af125e5bb99e373844dcd2e1c78b40b84011dd6d03feb54d487d12682df11565ba5494e06051e08f6767d273af25ddcf4b0579a78e5eed
|
|
7
|
+
data.tar.gz: ec329eab7fcc39c1028dc41554888de5597defdeca50e49bf0dee66a2fb58d4ade1b18ab69466619c62e38a5521a3a810c518b3da754d1eb2afc41ca6e49d86a
|
data/CHANGELOG.md
CHANGED
|
@@ -2,6 +2,58 @@
|
|
|
2
2
|
|
|
3
3
|
All notable changes to the `assinafy` Ruby gem are documented here.
|
|
4
4
|
|
|
5
|
+
## 1.6.0
|
|
6
|
+
|
|
7
|
+
### Added
|
|
8
|
+
|
|
9
|
+
- **OAuth 2.1 support.** An application can now act in a user's workspace with that user's
|
|
10
|
+
permission, instead of authenticating as the workspace with an API key.
|
|
11
|
+
|
|
12
|
+
`Assinafy::OAuth` covers the browser half of the authorization-code flow:
|
|
13
|
+
`generate_code_verifier`, `code_challenge` (PKCE S256, matching the RFC 7636 Appendix B test
|
|
14
|
+
vector), `generate_state`, and `authorization_url`. The authorization server accepts only
|
|
15
|
+
`S256`, so the challenge is always derived for you.
|
|
16
|
+
|
|
17
|
+
`client.oauth` covers the server half: `exchange_code`, `refresh`, `token`, `revoke`,
|
|
18
|
+
`userinfo`, `protected_resource_metadata`, and `authorization_server_metadata`. These routes
|
|
19
|
+
answer with flat RFC 6749 / OIDC objects rather than this API's `{status, data, message}`
|
|
20
|
+
envelope, and the SDK returns them unchanged. `/oauth/token` and `/oauth/revoke` identify the
|
|
21
|
+
client through `client_id` in the body, so the SDK strips `X-Api-Key`/`Authorization` from
|
|
22
|
+
them — including on `authorization_server_metadata`, which reaches a different host.
|
|
23
|
+
|
|
24
|
+
Pass the issued access token as `Assinafy::Client.new(token: ...)`.
|
|
25
|
+
|
|
26
|
+
- `Assinafy::OAuthError` (a subclass of `Assinafy::ApiError`, so existing `rescue` clauses keep
|
|
27
|
+
working) exposes `error` and `error_description` separately, instead of flattening
|
|
28
|
+
`invalid_grant` and its explanation into one message. On a `403` it carries the
|
|
29
|
+
`WWW-Authenticate` challenge — which names the missing scope — in `context[:www_authenticate]`.
|
|
30
|
+
|
|
31
|
+
- `AssignmentResource::VERIFICATION_METHODS` and `NOTIFICATION_METHODS` publish the signer
|
|
32
|
+
verification and notification enums: `Email` and `Whatsapp` one-time codes, and
|
|
33
|
+
`DigitalCertificate` signing with the signer's own ICP-Brasil A1/A3 certificate.
|
|
34
|
+
|
|
35
|
+
### Changed
|
|
36
|
+
|
|
37
|
+
- `AssignmentResource.build_payload` validates a signer's `verification_method`,
|
|
38
|
+
`notification_methods`, and `step` locally. The API's enums are closed and it reports an unknown
|
|
39
|
+
value as a `422` only after the request has been sent — and after any signers created for that
|
|
40
|
+
assignment already exist.
|
|
41
|
+
|
|
42
|
+
- `spec/fixtures/api_contract.json` tracks the current upstream contract (93 operations, 39
|
|
43
|
+
schemas), including the four OAuth operations.
|
|
44
|
+
|
|
45
|
+
### Removed
|
|
46
|
+
|
|
47
|
+
- **Steep type checking.** `steep` is no longer a development dependency, so the CI and release
|
|
48
|
+
workflows that ran `bundle exec steep check` would fail on any machine that installs from the
|
|
49
|
+
current gemspec. Those steps, the `Steepfile`, and the `typecheck/` stubs that existed only to
|
|
50
|
+
satisfy the checker are removed.
|
|
51
|
+
|
|
52
|
+
`sig/assinafy.rbs` is unchanged and still ships in the gemspec's file list: consumers keep the
|
|
53
|
+
published RBS signatures. In place of Steep, `spec/rbs_signature_spec.rb` asserts that every
|
|
54
|
+
public resource, `Client`, and `Assinafy::OAuth` method has a declared signature, so a new
|
|
55
|
+
method can no longer ship without one.
|
|
56
|
+
|
|
5
57
|
## 1.5.2
|
|
6
58
|
|
|
7
59
|
### Fixed
|