Skip to content

v1.5.1 - Critical Fix: Rate Limiting Per Certificate

Choose a tag to compare

View all tags
@Vitexus Vitexus released this 21 Nov 14:04
· 44 commits to main since this release
v1.5.1
7d72d7c

🔴 Critical Bug Fix

This release fixes a critical bug in the rate limiting implementation that was introduced in v1.5.0.

🐛 The Problem

The previous implementation incorrectly used X-IBM-Client-Id as the client identifier for rate limiting. However, according to the Raiffeisenbank Premium API documentation, rate limits are enforced per mTLS certificate, not per Client ID.

From the API documentation:

"The number of requests in each API operation is limited to 10 per client per sliding second..."

In the context of mTLS APIs, "client" means the certificate, not the X-IBM-Client-Id.

✅ The Fix

Rate limit tracking now correctly uses the SHA1 fingerprint of the mTLS client certificate as the client identifier.

What Changed

  • Added getCertificateFingerprint() method to calculate the SHA1 fingerprint of the certificate
  • Updated send() method to use certificate fingerprint instead of X-IBM-Client-Id
  • Updated the OpenAPI generator template (ApiClient.mustache) to preserve this fix in future regenerations
  • Updated documentation (WARP.md)
  • Removed version property from debian/composer.json (managed by debian/rules)

📊 Impact

Who is affected?

Users with multiple certificates registered under the same X-IBM-Client-Id will see different behavior.

Before (incorrect):

All requests using the same X-IBM-Client-Id shared one rate limit counter, regardless of which certificate was used.

After (correct):

Each certificate has its own independent rate limit counter, matching the actual API behavior.

🔄 Migration Notes

If you have stored rate limit state from v1.5.0:

  • The stored data will be reset because the client identifier has changed
  • This is expected behavior and does not cause any issues
  • Rate limits will be tracked correctly going forward

📝 Full Changelog

  • Fix rate limiting to use certificate fingerprint instead of X-IBM-Client-Id (#5)
  • Add getCertificateFingerprint() method for SHA1 certificate fingerprint calculation
  • Update ApiClient template to preserve fix in future code generations
  • Remove version property from debian/composer.json
  • Update documentation

⚠️ Breaking Change

If you were relying on rate limits being shared across multiple certificates with the same Client ID, this behavior will change. However, this change aligns with the actual API behavior and documentation.

Full diff: v1.5.0...v1.5.1

Assets 2
Loading