Ably's changelog
Ably's changelog
www.ably.com

Channel occupancy no longer includes dormant connections

 

Improvement

  

From later this week, realtime connections to Ably that have been detected as having been disconnected for over 15s (at which point they leave the presence set if they were present, but may still be resumed for the remainder of the two minute limit) will stop contributing occupancy to any channels that they were attached to. (Previously, the occupancy was maintained for the entire two minutes).

JavaScript Client Library SDK release v1.2.17

 

Client Library SDK Fix

  
  • Remove NPM preinstall script (this was breaking NPM installs when outside a git repository) #876

JavaScript Client Library SDK release v1.2.16

 

Client Library SDK Fix

  

Fixed bugs:

  • Fix bug where channel rewind would ignore messages after reattaching #873

.NET Client Library SDK release v1.2.6

 

Client Library SDK Improvement

  

Implemented enhancements:

Fixed bugs:

  • Call to Release (and ReleaseAll) does not impact channels in RealtimeChannels #980

JavaScript Client Library SDK release v1.2.15

 

Client Library SDK Fix

  

Fixed bugs

  • Replace deprecated request HTTP module with got #846
  • Improve checks for XHRRequest error responses #804

Introducing the Token Revocation API

 

New feature

  

We are pleased to introduce the Token Revocation API, which enhances our authentication capabilities.

Developers building with Ably have dynamic authorisation needs. Access permission to Ably channels should change based on the state of your application and the behaviour of your users.

The Token Revocation API is relevant to you if you wish to:

  • Programmatically change Ably channel permissions for users who are using your application.
  • Modify or remove access for a number of users at once.

For example, your application might include:

  • ‘Metered’ sessions that depend on a payment or subscription period. Access to Ably channels should change based on a user’s interaction with your application, such as funds being added, or a purchase.
  • The ability for moderators to exclude (or ‘kick’) another participant in a collaborative space, such as chat. In this case, the moderator removes that participant’s access to the Ably channel.
  • Live group sessions, such as online auctions, which at their end remove access from multiple participants at once.

We’re improving our support for these and similar use cases with the new API: it allows applications to programmatically revoke authorization tokens so they can either be replaced with new tokens with updated permissions, or to decline to re-issue a token at all.

The previously recommended way of supporting these use cases with Ably, instructing the client to discard their current token and fetch a new one, meant trusting the client. In most situations this was fine, but it would not be effective against the possibility of a rogue / compromised client ignoring the instruction to reauthorize and continuing to use its old token until that expires. With token revocation, your server can revoke authorization tokens remotely without having to trust the client. (The previous way still works and remains appropriate for situations where that threat model does not apply).

How do I get started?

The Token Revocation API is currently in Preview and has to be enabled for you by Ably. Contact us if you’d like to try this feature in your application.

Read the Token Revocation API documentation.

How do I give feedback?

We rely on your feedback to improve Ably. If you have any feedback we'd welcome issues or pull requests. You can also chat to the product team if you'd like to talk about contributing or feature requests.

Introducing the Ably Kafka Connector, beta

 

New feature

  

We are very excited to introduce the Ably Kafka Connector. It provides a ready-made integration between Kafka and Ably, allowing for realtime event distribution from Kafka to web, mobile, and IoT clients, over Ably’s feature-rich, multi-protocol pub/sub channels. This connector is verified by Confluent as Gold, following the guidelines set forth by Confluent’s Verified Integrations Program.

The Ably Kafka Connector makes it easy and seamless to use Ably as an internet-facing extension of Kafka. Both Ably and Kafka are event-driven solutions, sharing similar guarantees, messaging semantics, and characteristics. Kafka was built to work within a private network, and is not designed for distributing events between internal systems and consumers over the public internet. Ably was designed for edge streaming, and can act as the Internet-facing messaging layer to sit between Kafka and client devices when you’re extending Kafka to the edge.

How does the Ably Kafka Connector work?

The Ably Kafka Connector is a sink connector built on top of Kafka Connect. It can be self-hosted or hosted with a third-party provider — the most common being the Confluent Platform. You can download it from either GitHub or Confluent Cloud and install it into your Kafka Connect workers.

The Ably Kafka Connector provides a ready-made integration between Kafka and Ably via API Key. Once installed, you can configure the connector with your Ably API key to enable data from one or more Kafka topics to be published into a single Ably channel. Events are then distributed in realtime to web, mobile, and IoT clients over feature-rich, multi-protocol pub/sub Ably channels optimized for last-mile delivery.

how-ably-kafka-work-together (2).png

To see Ably and Kafka working together connected by the Ably Kafka Connector, you can follow this step-by-step technical tutorial for building a realtime ticket booking solution with Kafka, FastAPI, and Ably.

How do I get started?

The Ably Kafka Connector is a verified Gold connector on the Confluent Platform and can be installed from there if you’re deploying Kafka with Confluent. It can also be deployed locally using Docker. For more information on deployment and configuration, check out the documentation.

How do I give feedback?

The Ably Kafka Connector is available under the Apache 2 open source license and we are planning to continue extending and improving it, so we encourage feedback and feature requests; please either raise issues or pull requests if you would like to talk about contributing or feature requests. You can also contact us at any time.

32-byte API key secrets

 

Improvement

  

API keys are used to authenticate with the Ably platform's realtime and REST endpoints. A component of an API key is the key secret, which can be used to sign Ably JWT tokens using the HS256 algorithm. Per the specification, this value must be at least 32 bytes; Ably now produces 32-byte key secrets by default for compatibility with this specification.

This support for longer key secrets does not affect the operation of existing API keys. However, if you have opted to use Ably JWT tokens, you may consider cycling the relevant keys for additional security. Please refer to our API keys documentation for more information.

If you are storing an API key or key secret in fixed-width storage, you should check the maximum size of this field before using a 32-byte key secret, as the value will be longer.

This update is rolling out progressively over the week commencing 4th October, 2021.

How do I give feedback on this feature?

We rely on your feedback to improve this feature; please either raise issues or pull requests. You can also contact us at any time if you would like to talk about contributing or feature requests.

Java Client Library SDK version 1.2.10

 

Client Library SDK Fix

 

 

Fixes bug #715, affecting those supporting push notifications - users cannot reactivate device after deactivating.

JavaScript Client Library SDK release v1.2.14

 

Client Library SDK Fix

 

 

Fixed bugs

  • Add TypeScript support for REST publish parameters #785
  • Fix a bug with parsing of authUrl responses #793