|
| 1 | +# Changelog |
| 2 | + |
| 3 | +All notable changes to the Kinde Ruby SDK will be documented in this file. |
| 4 | + |
| 5 | +The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), |
| 6 | +and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). |
| 7 | + |
| 8 | +## [1.7.0] - 2024-12-19 |
| 9 | + |
| 10 | +### Added |
| 11 | + |
| 12 | +#### Entitlements Management |
| 13 | +- **New entitlements functionality** with comprehensive user entitlement management |
| 14 | +- `get_entitlements()` - Retrieve all user entitlements |
| 15 | +- `has_billing_entitlements?()` - Check if user has specific billing entitlements by price names |
| 16 | +- `has_entitlements?()` - Check if user has specific feature entitlements by keys |
| 17 | +- JavaScript SDK compatible aliases: `hasBillingEntitlements`, `hasEntitlements` |
| 18 | +- Full integration with Kinde's entitlements system for feature access control |
| 19 | + |
| 20 | +#### Hardcheck (Force API) Functionality |
| 21 | +- **New `force_api` configuration option** for controlling data retrieval method |
| 22 | +- **Soft check mode**: Extract user data from JWT token claims (faster, cached) |
| 23 | +- **Hard check mode**: Fetch fresh data from Kinde API (slower, always current) |
| 24 | +- **Smart fallback logic**: Automatically uses API when token claims are empty |
| 25 | +- **Method-level overrides**: Override global setting for specific method calls |
| 26 | +- **Environment variable support**: Configure via `KINDE_FORCE_API` environment variable |
| 27 | + |
| 28 | +#### Enhanced Permissions Management |
| 29 | +- `get_permissions()` - Get all user permissions with force_api support |
| 30 | +- `get_permission()` - Get specific permission status |
| 31 | +- `permission_granted?()` - Check if a specific permission is granted |
| 32 | +- `getPermissions()` - PHP SDK compatible alias with hard check |
| 33 | +- `getAllPermissions()` - Get all permissions with automatic pagination |
| 34 | +- Support for both standard and Hasura-specific permission claims |
| 35 | +- Graceful fallback from API to token-based permissions on errors |
| 36 | + |
| 37 | +#### Enhanced Roles Management |
| 38 | +- `get_roles()` - Get all user roles with smart fallback logic |
| 39 | +- `has_roles?()` - Check if user has specific roles |
| 40 | +- `getRoles()` - PHP SDK compatible alias with hard check |
| 41 | +- `hasRoles()` - JavaScript SDK compatible alias |
| 42 | +- Automatic fallback to API when token claims are empty |
| 43 | +- Consistent role data normalization across token and API sources |
| 44 | + |
| 45 | +#### Enhanced Feature Flags |
| 46 | +- `get_flags()` - Get all feature flags with force_api support |
| 47 | +- `get_flag()` - Get specific feature flag with type support (boolean, string, integer) |
| 48 | +- Support for default values when flags are not found |
| 49 | +- Backward compatibility with legacy 3-parameter calls |
| 50 | +- Graceful fallback from API to token-based flags on errors |
| 51 | + |
| 52 | +#### Comprehensive Logging System |
| 53 | +- **Configurable logging** that works with or without Rails |
| 54 | +- **Multiple log levels**: error, warning, info, debug |
| 55 | +- **Contextual logging** with module-specific prefixes |
| 56 | +- **Environment-based debug logging** via `KINDE_DEBUG` environment variable |
| 57 | +- **Graceful fallbacks** to STDERR/STDOUT when no logger is available |
| 58 | + |
| 59 | +### Enhanced |
| 60 | + |
| 61 | +#### Backward Compatibility |
| 62 | +- **Maintained full backward compatibility** with existing Ruby SDK API |
| 63 | +- **Legacy method support**: All existing methods continue to work unchanged |
| 64 | +- **Positional argument support**: Legacy 3-parameter method calls still supported |
| 65 | +- **Token type flexibility**: Support for both `:access_token` and `:id_token` types |
| 66 | + |
| 67 | +#### Error Handling |
| 68 | +- **Comprehensive error handling** with graceful fallbacks |
| 69 | +- **API error recovery**: Automatic fallback to token-based data when API calls fail |
| 70 | +- **Detailed error logging** for debugging and monitoring |
| 71 | +- **User-friendly error messages** with context |
| 72 | + |
| 73 | +#### Performance Optimizations |
| 74 | +- **Smart caching**: Use token claims when available to reduce API calls |
| 75 | +- **Efficient pagination**: Automatic handling of paginated API responses |
| 76 | +- **Conditional API calls**: Only call API when necessary or explicitly requested |
| 77 | +- **Optimized data extraction**: Streamlined parsing of API responses |
| 78 | + |
| 79 | +### Fixed |
| 80 | + |
| 81 | +#### Bug Fixes |
| 82 | +- **Fixed token claim extraction** for roles, permissions, and feature flags |
| 83 | +- **Improved error handling** for malformed or missing token claims |
| 84 | +- **Fixed pagination handling** for large datasets |
| 85 | +- **Resolved edge cases** in data normalization and field extraction |
| 86 | +- **Fixed logging configuration** to work across different Ruby environments |
| 87 | +- **Improved API response parsing** for various data formats |
| 88 | + |
| 89 | +#### API Integration |
| 90 | +- **Enhanced API endpoint integration** with proper error handling |
| 91 | +- **Improved token management** and bearer token validation |
| 92 | +- **Fixed data consistency** between token claims and API responses |
| 93 | +- **Resolved timing issues** with token refresh and API calls |
| 94 | + |
| 95 | +### Technical Improvements |
| 96 | + |
| 97 | +#### Code Quality |
| 98 | +- **Modular architecture**: Separated concerns into dedicated modules (Entitlements, Permissions, Roles, FeatureFlags) |
| 99 | +- **Comprehensive documentation**: Added detailed method documentation with examples |
| 100 | +- **Type safety**: Improved parameter validation and type checking |
| 101 | +- **Test coverage**: Enhanced test suite for new functionality |
| 102 | + |
| 103 | +#### Developer Experience |
| 104 | +- **Consistent API design**: Unified interface across all user data methods |
| 105 | +- **Flexible configuration**: Multiple ways to configure force_api behavior |
| 106 | +- **Rich debugging**: Enhanced logging and error reporting |
| 107 | +- **Clear migration path**: Backward compatibility ensures smooth upgrades |
| 108 | + |
| 109 | +### Dependencies |
| 110 | +- **Updated dependencies** for improved security and performance |
| 111 | +- **Enhanced Rails integration** with better initializer support |
| 112 | +- **Improved JWT handling** with better error recovery |
| 113 | + |
| 114 | +--- |
| 115 | + |
| 116 | +## [1.6.6] - Previous Release |
| 117 | + |
| 118 | +### Fixed |
| 119 | +- **Backward compatibility** for `get_user` method that was renamed to `get_user_profile_v2` in 1.6.5 |
| 120 | +- **Field mapping** between UserProfileV2 and legacy hash format |
| 121 | +- **Method aliasing** to maintain existing API contracts |
| 122 | + |
| 123 | +--- |
| 124 | + |
| 125 | +*For migration guides and detailed usage examples, see the [README.md](README.md) and [BACKWARD_COMPATIBILITY.md](BACKWARD_COMPATIBILITY.md) files.* |
0 commit comments