Skip to content

Releases: interledger/rafiki

v2.2.0-beta

31 Oct 16:22
@github-actions github-actions
v2.2.0-beta
77a0c2a
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v2.2.0-beta Latest
Latest

✨ New Features

Contributors

mkurapov
Assets 2
Loading

v2.1.0-beta

30 Oct 18:59
@github-actions github-actions
v2.1.0-beta
8b1ec9c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v2.1.0-beta

✨ New Features

The subject field feature in the Open Payments auth server adds a way for Open Payment clients to simply verify the ownership of a wallet address, without requiring an outgoing payment grant.

For integrators, this concerns the IDP behaviour. Now, when the IDP requests a grant lookup (you can see the updated OpenAPI specs here), instead of (or alongside) the access_token, it's possible to get back a subject field in the following format:

"subject": {
    "sub_ids": [
      {
        "id": "{{walletAddress}}",
        "format": "uri"
      }
    ]
  }

Here, the IDP must verify that the end user does in fact own the requested wallet address, which means updating the consent screen with the proper verbiage for the user. As an example, in the mock ASE, when the subject is requested, the consent screen presents "{thirdPartyName} is asking you to confirm ownership of {walletAddress} wallet address".

Updating the consent screen, and making the check that the wallet address belongs to the user going through the interaction are the required changes in the IDP. Approve & finish behaviour remains the same.

Behaviour change: Whenever a wallet address is fetched using Open Payments API, we send a wallet_address.not_found webhook in order for the ASE to have an opportunity to create a wallet address "on the fly". Previously, this was enabled by default, and now, this is disabled by default. If you need to enable this, you will need to enable WALLET_ADDRESS_NOT_FOUND_POLLING_ENABLED flag in backend.

🐛 Bug Fixes

Made sure that during hash generating in the auth server, we use the full grant URL/auth server URL along with the tenantId.

🔧 Chores

Full Changelog: v2.0.0-beta...v2.1.0-beta

Contributors

renovate, cozminu, and mkurapov
Loading

v1.2.1-beta

27 Oct 14:25
@github-actions github-actions
v1.2.1-beta
fdedc33
This commit was signed with the committer’s verified signature.
mkurapov Max Kurapov
GPG key ID: CA36DD4C6AF8CB2C
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.2.1-beta

✨ New Features

Behaviour change: Whenever a wallet address is fetched using Open Payments API, we send a wallet_address.not_found webhook in order for the ASE to have an opportunity to create a wallet address "on the fly". Previously, this was enabled by default, and now, this is disabled by default. If you need to enable this, you will need to enable WALLET_ADDRESS_NOT_FOUND_POLLING_ENABLED flag in backend.

🐛 Bug Fixes

✅ Tests

Contributors

cozminu and mkurapov
Loading

v2.0.0-beta

16 Oct 19:41
@github-actions github-actions
v2.0.0-beta
f8709db
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v2.0.0-beta

🚀 Multi-tenancy support added

Overview

In this release, we have added support for multi-tenancy in Rafiki. This allows single Rafiki instance to service multiple account servicing entities (ASEs).

There is no "opt out" of multi-tenancy, Rafiki is multi-tenant by default.

Migration guide

The entity responsible for managing a Rafiki instance that serves multiple ASEs is called an operator. When upgrading from v1-beta version of Rafiki to v2-beta, an operator tenant is seeded automatically (given the environment variables below) and all of the existing resources are backfilled to reference the operator tenant.

An operator is then able to create individual tenants, and create, manage resources & liquidity for them. This is done through the backend Admin API. The tenant details/settings (and the updates to those details) are propagated to the auth service with a new "tenant" auth API.

At a high level, the main changes require:

  1. Generating a V4 UUID to set as the operator id
  2. Start signing Admin API requests to both backend and auth APIs, if not done so already. This is necessary to determine which tenant is making a request to the APIs.
  3. Expose the tenant API in auth to listen to any tenant information changes propagated from backend.
Necessary auth changes
  1. Set OPERATOR_TENANT_ID to a V4 UUID.
  2. ADMIN_API_SECRET to a strong, random secret.
  3. Expose the tenant service API port (by default it is 3011). This is to listen to any changes to the tenant information from backend.
Necessary backend changes
  1. Set OPERATOR_TENANT_ID to a V4 UUID (the same as the auth).
  2. Set ADMIN_API_SECRET to a strong, random secret. (for ease of use when signing requests, set it to same as the auth).
    Please note, if you were already signing the Admin API requests to backend, API_SECRET was renamed to ADMIN_API_SECRET, and API_SIGNATURE_VERSION was renamed to API_SIGNATURE_VERSION.
  3. Set AUTH_SERVICE_API_URL to the full URL of new exposed tenant auth service.
Necessary frontend changes
  1. When first interacting with frontend, the tenant (or operator) credentials must be entered akin to a login screen.
Necessary changes to your integration server
  1. Update createWalletAddress mutation input. Now, instead of a full url path, the mutation takes in address, which could be a full URL or just a path. If a path is entered, it will act as a suffix to the defined OPEN_PAYMENTS_URL if the request is on behalf of an operator, or a suffix to the defined wallet address URL tenant setting, if the request is from a non-operator tenant.
  2. Update walletAddress resolver to fetch address instead of url.
  3. Start signing requests to the backend and auth Admin APIs. An example of signing requests with the Apollo GraphQL client can be found in our mock-ase here.
    Example code:
const httpLink = new HttpLink({
  uri: process.env.ADMIN_API_URL,
  enhancedClientAwareness: { transport: false } // necessary to avoid adding additional properties into request object
});

const createAuthLink = (args: { tenantId: string, apiSecret: string, signatureVersion: number }) => {
  return setContext((request, { headers }) => {
    
    const timestamp = Date.now()

    const { query, variables, operationName } = request
    const formattedRequest = {
      variables,
      operationName,
      query: print(query)
    }

    const payload = `${timestamp}.${canonicalize(formattedRequest)}`
    
    const digest = createHmac('sha256', args.apiSecret)
      .update(payload)
      .digest('hex')

    return {
      headers: {
        ...headers,
        signature: `t=${timestamp}, v${args.signatureVersion}=${digest}`,
        ['tenant-id']: args.tenantId
      }
    };
  })
}

✨ New Features

🐛 Bug Fixes

🔧 Chores

Contributors

huijing, cozminu, and 5 other contributors
Loading

v1.2.0-beta

04 Jul 09:37
@github-actions github-actions
v1.2.0-beta
33e54d5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.2.0-beta

💥 BREAKING CHANGES

  • due to 16b501e - removed 'updatedAt' from incoming and outgoing payments responses from OP (PR #3429 by @oana-lolea):
    • This change removes updatedAt from incoming and outgoing payments in Open Payments and the backend Admin API GraphQL schema. This means you will need to remove updatedAt field from mutations and queries that resolve incoming and outgoing payments when making requests to the backend Admin API.
    • Grant request for outgoing payments limits (Open Payments API) can take in debitAmount XOR receiveAmount (instead of allowing both)

✨ New Features

  • f5b325f - localenv: add histogram for outgoing payment completion time (PR #3438 by @njlie)
  • 7d8079f - backend: return minSendAmount in quote responses (PR #3411 by @cozminu)
    • Now, we are returning objects in the resource server responses, instead of just text. In addition, for some quoting errors, we return a minSendAmount to specify the minimum amount the sender needs to add in the quote for it to succeed. For example, POST /quotes in Open Payments for an amount that cannot be satifsfied would return an error object like this:
{
  "error": {
    "code": "400",
    "description": "non-positive receive amount",
    "details": {
      "minSendAmount": {
        "value": "112",
        "assetCode": "USD",
        "assetScale": 2
      }
    }
  }
}

🐛 Bug Fixes

🔧 Chores

🔧 Supported versions

  • Supports Open Payments NodeJS clients >= 7.0.0
  • TigerBeetle: Oldest upgradable replica version: 0.16.25

Contributors

huijing, cozminu, and 4 other contributors
Loading

v1.1.2-beta

12 May 11:28
@github-actions github-actions
v1.1.2-beta
6488c55
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.1.2-beta

✨ New Features

🐛 Bug Fixes

  • 6488c55 - backend: local payments - allow multiple outgoing payments pay into single incoming (PR #3428 by @mkurapov)

Contributors

cozminu and mkurapov
Loading

v1.1.1-beta

17 Apr 10:15
@github-actions github-actions
v1.1.1-beta
ebb58c7
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.1.1-beta

✨ New Features

🔧 Chores

Supported versions

  • TigerBeetle: Oldest upgradable replica version: 0.16.25
  • Open Payments Node SDK: 6.x.x

Contributors

huijing and cozminu
Loading

v1.1.0-beta

07 Apr 18:58
@github-actions github-actions
v1.1.0-beta
a601e64
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.1.0-beta

✨ New Features

  • 1cd0790 - backend: better errors during token introspection in RS (PR #3346 by @cozminu)
    • For Open Payments clients, we now differentiate between "Inactive Token" vs "Insufficient Grant" errors when making a request to the resource server. For the former, an Open Payments client will simply need to rotate the token, for the latter, a new grant must be requested with the correct permissions for the resource.
  • 3d40648 - auth: use gnap error middleware on idp api (PR #3094 by @njlie)
    • Now, errors from the IDP server return properly formatted objects, similar to the errors thrown in the AS
  • 5c7f1fa - auth: handle expired interactions gracefully during finish (PR #3340 by @njlie)
    • Improved IDP error handling: redirect back to the client when possible, providing better error descriptions in redirect URL, particularly during expired interactions
  • ce17e0f - backend: redirect to webpage when querying payment pointer in browser (PR #3298 by @cozminu)
    • Now, integrators can set WALLET_ADDRESS_REDIRECT_HTML_PAGE env flag which will allow doing a 302 redirect to a webpage for a wallet address query, if the accept header of the incoming request istext/html(typically from a browser)
  • 36107b1 - backend: unique keys per wallet address (PR #2863 by @sabineschaller, @oana-lolea)
  • ee45d61 - docs: added basic site tracking using Umami (PR #3157 by @JoblersTune)
  • 636a1ca - backend: check grant receiver to match quote receiver (PR #3248 by @cozminu)
  • 308ed37 - backend: Check quote expiry in outgoing payment worker (#3141) (PR #3173 by @CollinsMunene)
  • 286f146 - backend: bump tb from 0.15.4 to 0.16.29 (PR #3323 by @koekiebox)
  • 7d197f3 - webhook: provide grant id in outgoing payment events (PR #3335 by @dragosp1011)
  • ba7cac7 - backend: directly use resource server URL to generate URLs for OP (PR #3341 by @cozminu)
  • f57695b - backend,mase: admin api healthcheck (PR #3199 by @BlairCurrey)
  • cbd3a0c - backend: deadlocks (PR #3320 by @BlairCurrey)

🐛 Bug Fixes

  • 0b4cac3 - backend: await signature verification (PR #3175 by @mkurapov)
    • Signature verification for backend API was fixed. If you have API_SECRET set in the environment variables for securing the backend Admin API, and you are not signing the GraphQL requests, you will being seeing a 401 Unauthorized error. Please start signing your Admin API requests, or remove API_SECRET environment variable until you are able to sign requests.
  • 7f1a822 - mock-ase: process is undefined error in client (PR #3275 by @cozminu)
  • a338e5d - backend: allow admin api to query all receivers and move checks (PR #3314 by @cozminu)

🔧 Chores

Read more

Contributors

renovate, koekiebox, and 9 other contributors
Loading

v1.0.1-beta

10 Dec 14:08
@github-actions github-actions
v1.0.1-beta
cc9ef41
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.0.1-beta

🔧 Chores

Compatibility

  • Open Payments client: 6.x.x
  • TigerBeetle: 0.15.4

Contributors

mkurapov
Loading

v1.0.0-beta

09 Dec 12:39
@github-actions github-actions
v1.0.0-beta
b83ac58
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Choose a tag to compare

View all tags
v1.0.0-beta

✨ New Features

🐛 Bug Fixes

🔧 Chores

Compatibility

  • Open Payments clients: 6.x.x
  • TigerBeetle: 0.15.4

Contributors

renovate, koekiebox, and 7 other contributors
Loading