miso-client 0.1.0__tar.gz → 0.4.0__tar.gz
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.
Potentially problematic release.
This version of miso-client might be problematic. Click here for more details.
- miso_client-0.4.0/CHANGELOG.md +351 -0
- {miso_client-0.1.0/miso_client.egg-info → miso_client-0.4.0}/PKG-INFO +165 -3
- {miso_client-0.1.0 → miso_client-0.4.0}/README.md +164 -2
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/__init__.py +104 -84
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/errors.py +30 -4
- miso_client-0.4.0/miso_client/models/__init__.py +5 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/models/config.py +56 -35
- miso_client-0.4.0/miso_client/models/error_response.py +41 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/__init__.py +5 -5
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/auth.py +65 -48
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/cache.py +42 -41
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/encryption.py +18 -17
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/logger.py +115 -100
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/permission.py +27 -36
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/redis.py +17 -15
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/services/role.py +25 -36
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/utils/__init__.py +3 -3
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/utils/config_loader.py +24 -16
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/utils/data_masker.py +104 -33
- miso_client-0.4.0/miso_client/utils/http_client.py +585 -0
- miso_client-0.1.0/miso_client/utils/http_client.py → miso_client-0.4.0/miso_client/utils/internal_http_client.py +182 -88
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/utils/jwt_tools.py +14 -17
- miso_client-0.4.0/miso_client/utils/sensitive_fields_loader.py +116 -0
- {miso_client-0.1.0 → miso_client-0.4.0/miso_client.egg-info}/PKG-INFO +165 -3
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client.egg-info/SOURCES.txt +4 -1
- {miso_client-0.1.0 → miso_client-0.4.0}/pyproject.toml +1 -1
- {miso_client-0.1.0 → miso_client-0.4.0}/setup.py +1 -1
- miso_client-0.1.0/CHANGELOG.md +0 -199
- miso_client-0.1.0/miso_client/models/__init__.py +0 -1
- {miso_client-0.1.0 → miso_client-0.4.0}/LICENSE +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/MANIFEST.in +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client/py.typed +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client.egg-info/dependency_links.txt +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client.egg-info/not-zip-safe +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client.egg-info/requires.txt +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/miso_client.egg-info/top_level.txt +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/pytest.ini +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/requirements-test.txt +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/requirements.txt +0 -0
- {miso_client-0.1.0 → miso_client-0.4.0}/setup.cfg +0 -0
|
@@ -0,0 +1,351 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to the MisoClient 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
|
+
## [0.4.0] - 2025-11-02
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
|
|
12
|
+
- **ISO 27001 Compliant HTTP Client with Automatic Audit and Debug Logging**: New public `HttpClient` class that wraps `InternalHttpClient` with automatic ISO 27001 compliant audit and debug logging
|
|
13
|
+
- Automatic audit logging for all HTTP requests (`http.request.{METHOD}` format)
|
|
14
|
+
- Debug logging when `log_level === 'debug'` with detailed request/response information
|
|
15
|
+
- Automatic data masking using `DataMasker` before logging (ISO 27001 compliant)
|
|
16
|
+
- All request headers are masked (Authorization, x-client-token, Cookie, etc.)
|
|
17
|
+
- All request bodies are recursively masked for sensitive fields (password, token, secret, SSN, etc.)
|
|
18
|
+
- All response bodies are masked (limited to first 1000 characters)
|
|
19
|
+
- Query parameters are automatically masked
|
|
20
|
+
- Error messages are masked if they contain sensitive data
|
|
21
|
+
- Sensitive endpoints (`/api/logs`, `/api/auth/token`) are excluded from audit logging to prevent infinite loops
|
|
22
|
+
- JWT user ID extraction from Authorization headers for audit context
|
|
23
|
+
- Request duration tracking for performance monitoring
|
|
24
|
+
- Request/response size tracking for observability
|
|
25
|
+
|
|
26
|
+
- **JSON Configuration Support for DataMasker**: Enhanced `DataMasker` with JSON configuration file support for sensitive fields
|
|
27
|
+
- New `sensitive_fields_config.json` file with default ISO 27001 compliant sensitive fields
|
|
28
|
+
- Categories: authentication, pii, security
|
|
29
|
+
- Support for custom configuration path via `MISO_SENSITIVE_FIELDS_CONFIG` environment variable
|
|
30
|
+
- `DataMasker.set_config_path()` method for programmatic configuration
|
|
31
|
+
- Automatic merging of JSON fields with hardcoded defaults (fallback if JSON cannot be loaded)
|
|
32
|
+
- Backward compatible - existing hardcoded fields still work as fallback
|
|
33
|
+
|
|
34
|
+
- **New InternalHttpClient Class**: Separated core HTTP functionality into `InternalHttpClient` class
|
|
35
|
+
- Pure HTTP functionality with automatic client token management (no logging)
|
|
36
|
+
- Used internally by public `HttpClient` for actual HTTP requests
|
|
37
|
+
- Used by `LoggerService` for sending logs to prevent circular dependencies
|
|
38
|
+
- Not exported in public API (internal use only)
|
|
39
|
+
|
|
40
|
+
- **New sensitive_fields_loader Module**: Utility module for loading and merging sensitive fields configuration
|
|
41
|
+
- `load_sensitive_fields_config()` function for loading JSON configuration
|
|
42
|
+
- `get_sensitive_fields_array()` function for flattened sensitive fields list
|
|
43
|
+
- `get_field_patterns()` function for pattern matching rules
|
|
44
|
+
- Support for custom configuration paths via environment variables
|
|
45
|
+
|
|
46
|
+
### Changed
|
|
47
|
+
|
|
48
|
+
- **Breaking Change: HttpClient Constructor**: Public `HttpClient` constructor now requires `logger` parameter
|
|
49
|
+
- Old: `HttpClient(config)`
|
|
50
|
+
- New: `HttpClient(config, logger)`
|
|
51
|
+
- This is handled automatically when using `MisoClient` - no changes needed for typical usage
|
|
52
|
+
- Only affects code that directly instantiates `HttpClient`
|
|
53
|
+
|
|
54
|
+
- **Breaking Change: LoggerService Constructor**: `LoggerService` constructor now uses `InternalHttpClient` instead of `HttpClient`
|
|
55
|
+
- Old: `LoggerService(http_client: HttpClient, redis: RedisService)`
|
|
56
|
+
- New: `LoggerService(internal_http_client: InternalHttpClient, redis: RedisService)`
|
|
57
|
+
- This is handled automatically when using `MisoClient` - no changes needed for typical usage
|
|
58
|
+
- Prevents circular dependency (LoggerService uses InternalHttpClient for log sending)
|
|
59
|
+
|
|
60
|
+
- **MisoClient Architecture**: Updated `MisoClient` constructor to use new HttpClient architecture
|
|
61
|
+
- Creates `InternalHttpClient` first (pure HTTP functionality)
|
|
62
|
+
- Creates `LoggerService` with `InternalHttpClient` (prevents circular dependency)
|
|
63
|
+
- Creates public `HttpClient` wrapping `InternalHttpClient` with logger (adds audit/debug logging)
|
|
64
|
+
- All services now use public `HttpClient` with automatic audit logging
|
|
65
|
+
|
|
66
|
+
- **DataMasker Enhancement**: Updated `DataMasker` to load sensitive fields from JSON configuration
|
|
67
|
+
- Maintains backward compatibility with hardcoded fields as fallback
|
|
68
|
+
- Automatic loading on first use with caching
|
|
69
|
+
- Support for custom configuration paths
|
|
70
|
+
|
|
71
|
+
### ISO 27001 Compliance Features
|
|
72
|
+
|
|
73
|
+
- **Automatic Data Masking**: All sensitive data is automatically masked before logging
|
|
74
|
+
- Request headers: Authorization, x-client-token, Cookie, Set-Cookie, and any header containing sensitive keywords
|
|
75
|
+
- Request bodies: Recursively masks password, token, secret, SSN, creditcard, CVV, PIN, OTP, API keys, etc.
|
|
76
|
+
- Response bodies: Especially important for error responses that might contain sensitive data
|
|
77
|
+
- Query parameters: Automatically extracted and masked
|
|
78
|
+
- Error messages: Masked if containing sensitive data
|
|
79
|
+
|
|
80
|
+
- **Audit Log Structure**: Standardized audit log format for all HTTP requests
|
|
81
|
+
- Action: `http.request.{METHOD}` (e.g., `http.request.GET`, `http.request.POST`)
|
|
82
|
+
- Resource: Request URL path
|
|
83
|
+
- Context: method, url, statusCode, duration, userId, requestSize, responseSize, error (all sensitive data masked)
|
|
84
|
+
|
|
85
|
+
- **Debug Log Structure**: Detailed debug logging when `log_level === 'debug'`
|
|
86
|
+
- All audit context fields plus: requestHeaders, responseHeaders, requestBody, responseBody (all masked)
|
|
87
|
+
- Additional context: baseURL, timeout, queryParams (all sensitive data masked)
|
|
88
|
+
|
|
89
|
+
### Technical Improvements
|
|
90
|
+
|
|
91
|
+
- Improved error handling: Logging errors never break HTTP requests (all errors caught and swallowed)
|
|
92
|
+
- Performance: Async logging that doesn't block request/response flow
|
|
93
|
+
- Safety: Sensitive endpoints excluded from audit logging to prevent infinite loops
|
|
94
|
+
- Flexibility: Configurable sensitive fields via JSON configuration file
|
|
95
|
+
|
|
96
|
+
---
|
|
97
|
+
|
|
98
|
+
## [0.3.0] - 2025-11-01
|
|
99
|
+
|
|
100
|
+
### Added
|
|
101
|
+
|
|
102
|
+
- **Structured Error Response Interface**: Added generic `ErrorResponse` model following RFC 7807-style format for consistent error handling across applications
|
|
103
|
+
- `ErrorResponse` Pydantic model with fields: `errors`, `type`, `title`, `statusCode`, `instance`
|
|
104
|
+
- Automatic parsing of structured error responses from HTTP responses in `HttpClient`
|
|
105
|
+
- Support for both camelCase (`statusCode`) and snake_case (`status_code`) field names
|
|
106
|
+
- `MisoClientError` now includes optional `error_response` field with structured error information
|
|
107
|
+
- Enhanced error messages automatically generated from structured error responses
|
|
108
|
+
- Instance URI automatically extracted from request URL when not provided in response
|
|
109
|
+
- Backward compatible - falls back to traditional `error_body` dict when structured format is not available
|
|
110
|
+
- Export `ErrorResponse` from main module for reuse in other applications
|
|
111
|
+
- Comprehensive test coverage for error response parsing and fallback behavior
|
|
112
|
+
- Full type safety with Pydantic models
|
|
113
|
+
|
|
114
|
+
### Changed
|
|
115
|
+
|
|
116
|
+
- **Error Handling**: `MisoClientError` now prioritizes structured error information when available
|
|
117
|
+
- Error messages are automatically enhanced from structured error responses
|
|
118
|
+
- Status codes are extracted from structured responses when provided
|
|
119
|
+
|
|
120
|
+
---
|
|
121
|
+
|
|
122
|
+
## [0.2.0] - 2025-10-31
|
|
123
|
+
|
|
124
|
+
### Added
|
|
125
|
+
|
|
126
|
+
- **API_KEY Support for Testing**: Added optional `API_KEY` environment variable that allows bypassing OAuth2 authentication for testing purposes
|
|
127
|
+
- When `API_KEY` is set in environment, bearer tokens matching the key will automatically validate without OAuth2
|
|
128
|
+
- `validate_token()` returns `True` for matching API_KEY tokens without calling controller
|
|
129
|
+
- `get_user()` and `get_user_info()` return `None` when using API_KEY (by design for testing scenarios)
|
|
130
|
+
- Configuration supports `api_key` field in `MisoClientConfig`
|
|
131
|
+
- Comprehensive test coverage for API_KEY authentication flows
|
|
132
|
+
- Useful for testing without requiring Keycloak setup
|
|
133
|
+
|
|
134
|
+
- **PowerShell Makefile**: Added `Makefile.ps1` with all development commands for Windows PowerShell users
|
|
135
|
+
- Replaces `dev.bat` and `dev.ps1` scripts with unified PowerShell Makefile
|
|
136
|
+
- Supports all standard development commands (install, test, lint, format, build, etc.)
|
|
137
|
+
- Consistent interface with Unix Makefile
|
|
138
|
+
|
|
139
|
+
- **Validate Command**: Added new `validate` target to both Makefile and Makefile.ps1
|
|
140
|
+
- Runs lint + format + test in sequence
|
|
141
|
+
- Useful for pre-commit validation and CI/CD pipelines
|
|
142
|
+
- Usage: `make validate` or `.\Makefile.ps1 validate`
|
|
143
|
+
|
|
144
|
+
### Changed
|
|
145
|
+
|
|
146
|
+
- **Development Scripts**: Replaced `dev.bat` and `dev.ps1` with `Makefile.ps1` for better consistency
|
|
147
|
+
- All development commands now available through Makefile interface
|
|
148
|
+
- Improved cross-platform compatibility
|
|
149
|
+
|
|
150
|
+
### Testing
|
|
151
|
+
|
|
152
|
+
- Added comprehensive test suite for API_KEY functionality
|
|
153
|
+
- Tests for `validate_token()` with API_KEY matching and non-matching scenarios
|
|
154
|
+
- Tests for `get_user()` and `get_user_info()` with API_KEY
|
|
155
|
+
- Tests for config loader API_KEY loading
|
|
156
|
+
- All tests verify OAuth2 fallback behavior when API_KEY doesn't match
|
|
157
|
+
|
|
158
|
+
---
|
|
159
|
+
|
|
160
|
+
## [0.1.0] - 2025-10-30
|
|
161
|
+
|
|
162
|
+
### Added
|
|
163
|
+
|
|
164
|
+
- **Automatic Client Token Management in HttpClient**: Client tokens are now automatically fetched, cached, and refreshed by the HttpClient
|
|
165
|
+
- Proactive token refresh when < 60 seconds until expiry (30 second buffer before actual expiration)
|
|
166
|
+
- Automatic `x-client-token` header injection for all requests
|
|
167
|
+
- Concurrent token fetch prevention using async locks
|
|
168
|
+
- Automatic token clearing on 401 responses to force refresh
|
|
169
|
+
|
|
170
|
+
- **New Data Models**:
|
|
171
|
+
- `ClientTokenResponse`: Response model for client token requests with expiration tracking
|
|
172
|
+
- `PerformanceMetrics`: Performance metrics model for logging (start time, end time, duration, memory usage)
|
|
173
|
+
- `ClientLoggingOptions`: Advanced logging options with JWT context extraction, correlation IDs, data masking, and performance metrics support
|
|
174
|
+
|
|
175
|
+
- **RedisConfig Enhancement**:
|
|
176
|
+
- Added `db` field to specify Redis database number (default: 0)
|
|
177
|
+
- Supports multi-database Redis deployments
|
|
178
|
+
|
|
179
|
+
### Changed
|
|
180
|
+
|
|
181
|
+
- **Module Structure**: Moved type definitions from `miso_client.types.config` to `miso_client.models.config` for better organization
|
|
182
|
+
- All imports now use `from miso_client.models.config import ...`
|
|
183
|
+
- Previous compatibility layer (`types_backup_test`) removed as no longer needed
|
|
184
|
+
|
|
185
|
+
- **HttpClient Improvements**:
|
|
186
|
+
- Client token management is now fully automatic - no manual token handling required
|
|
187
|
+
- Better error handling with automatic token refresh on authentication failures
|
|
188
|
+
- All HTTP methods (GET, POST, PUT, DELETE) now automatically include client token header
|
|
189
|
+
|
|
190
|
+
### Technical Improvements
|
|
191
|
+
|
|
192
|
+
- Improved token expiration handling with proactive refresh mechanism
|
|
193
|
+
- Reduced API calls through intelligent token caching
|
|
194
|
+
- Better concurrency handling with async locks for token operations
|
|
195
|
+
- Enhanced error recovery with automatic token clearing on 401 responses
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
|
|
199
|
+
## [0.1.0] - 2025-10-01
|
|
200
|
+
|
|
201
|
+
### Added
|
|
202
|
+
|
|
203
|
+
- **Initial Release**: Complete MisoClient SDK implementation
|
|
204
|
+
- **Authentication**: JWT token validation and user management
|
|
205
|
+
- **Authorization**: Role-based access control (RBAC) with Redis caching
|
|
206
|
+
- **Permissions**: Fine-grained permission management with caching
|
|
207
|
+
- **Logging**: Structured logging with Redis queuing and HTTP fallback
|
|
208
|
+
- **Redis Integration**: Optional Redis caching for improved performance
|
|
209
|
+
- **Async Support**: Full async/await support for modern Python applications
|
|
210
|
+
- **Type Safety**: Complete type hints and Pydantic models
|
|
211
|
+
- **Graceful Degradation**: Works with or without Redis
|
|
212
|
+
- **Comprehensive Documentation**: Complete API reference and integration guides
|
|
213
|
+
- **Unit Tests**: Full test coverage mirroring TypeScript implementation
|
|
214
|
+
- **Package Distribution**: Ready for PyPI distribution with setup.py and pyproject.toml
|
|
215
|
+
|
|
216
|
+
### Features
|
|
217
|
+
|
|
218
|
+
#### Core Client
|
|
219
|
+
- `MisoClient` main class with initialization and lifecycle management
|
|
220
|
+
- Configuration management with `MisoClientConfig` and `RedisConfig`
|
|
221
|
+
- Connection state tracking and graceful fallback
|
|
222
|
+
|
|
223
|
+
#### Authentication Service
|
|
224
|
+
- Token validation with controller integration
|
|
225
|
+
- User information retrieval
|
|
226
|
+
- Login URL generation for web applications
|
|
227
|
+
- Logout functionality
|
|
228
|
+
|
|
229
|
+
#### Role Service
|
|
230
|
+
- Role retrieval with Redis caching (15-minute TTL)
|
|
231
|
+
- Role checking methods: `has_role`, `has_any_role`, `has_all_roles`
|
|
232
|
+
- Role refresh functionality to bypass cache
|
|
233
|
+
- Cache key management with user/environment/application scoping
|
|
234
|
+
|
|
235
|
+
#### Permission Service
|
|
236
|
+
- Permission retrieval with Redis caching (15-minute TTL)
|
|
237
|
+
- Permission checking methods: `has_permission`, `has_any_permission`, `has_all_permissions`
|
|
238
|
+
- Permission refresh functionality to bypass cache
|
|
239
|
+
- Cache clearing functionality
|
|
240
|
+
- Cache key management with user/environment/application scoping
|
|
241
|
+
|
|
242
|
+
#### Logger Service
|
|
243
|
+
- Structured logging with multiple levels: `info`, `error`, `audit`, `debug`
|
|
244
|
+
- Redis queue integration for log batching
|
|
245
|
+
- HTTP fallback when Redis is unavailable
|
|
246
|
+
- Context-aware logging with metadata support
|
|
247
|
+
|
|
248
|
+
#### HTTP Client
|
|
249
|
+
- Async HTTP client wrapper using httpx
|
|
250
|
+
- Automatic header injection (X-Environment, X-Application)
|
|
251
|
+
- Authenticated request support with Bearer token
|
|
252
|
+
- Error handling and status code management
|
|
253
|
+
|
|
254
|
+
#### Redis Service
|
|
255
|
+
- Async Redis integration using redis.asyncio
|
|
256
|
+
- Graceful degradation when Redis is unavailable
|
|
257
|
+
- Connection state tracking
|
|
258
|
+
- Key prefix support for multi-tenant environments
|
|
259
|
+
|
|
260
|
+
### Data Models
|
|
261
|
+
|
|
262
|
+
- `UserInfo`: User information from token validation
|
|
263
|
+
- `AuthResult`: Authentication result structure
|
|
264
|
+
- `LogEntry`: Structured log entry format
|
|
265
|
+
- `RoleResult`: Role query result
|
|
266
|
+
- `PermissionResult`: Permission query result
|
|
267
|
+
- `MisoClientConfig`: Main client configuration
|
|
268
|
+
- `RedisConfig`: Redis connection configuration
|
|
269
|
+
|
|
270
|
+
### Integration Examples
|
|
271
|
+
|
|
272
|
+
- **FastAPI**: Complete integration with dependencies and middleware
|
|
273
|
+
- **Django**: Middleware, decorators, and view integration
|
|
274
|
+
- **Flask**: Decorator-based authentication and authorization
|
|
275
|
+
- **Custom Applications**: Dependency injection and service patterns
|
|
276
|
+
|
|
277
|
+
### Documentation
|
|
278
|
+
|
|
279
|
+
- **README.md**: Comprehensive SDK documentation with quick start guide
|
|
280
|
+
- **API Reference**: Detailed method signatures and parameter descriptions
|
|
281
|
+
- **Integration Guide**: Framework-specific integration examples
|
|
282
|
+
- **Changelog**: Version history and feature tracking
|
|
283
|
+
|
|
284
|
+
### Testing
|
|
285
|
+
|
|
286
|
+
- **Unit Tests**: Comprehensive test coverage for all services
|
|
287
|
+
- **Mock Support**: Mock implementations for testing
|
|
288
|
+
- **Error Handling**: Test coverage for error scenarios and edge cases
|
|
289
|
+
- **Performance Tests**: Concurrent operation testing
|
|
290
|
+
|
|
291
|
+
### Package Management
|
|
292
|
+
|
|
293
|
+
- **setup.py**: Traditional Python package configuration
|
|
294
|
+
- **pyproject.toml**: Modern Python packaging (PEP 518)
|
|
295
|
+
- **Dependencies**: httpx, redis[hiredis], pydantic, pydantic-settings, structlog
|
|
296
|
+
- **Development Dependencies**: pytest, black, isort, mypy
|
|
297
|
+
- **Python Support**: Python 3.8+ compatibility
|
|
298
|
+
|
|
299
|
+
### Security
|
|
300
|
+
|
|
301
|
+
- **Token Handling**: Secure JWT token processing
|
|
302
|
+
- **Redis Security**: Password and key prefix support
|
|
303
|
+
- **Logging Security**: Careful handling of sensitive information
|
|
304
|
+
- **Error Handling**: Graceful error handling without information leakage
|
|
305
|
+
|
|
306
|
+
### Performance
|
|
307
|
+
|
|
308
|
+
- **Caching**: Redis-based caching for roles and permissions
|
|
309
|
+
- **Connection Pooling**: Efficient HTTP and Redis connection management
|
|
310
|
+
- **Async Operations**: Non-blocking async/await throughout
|
|
311
|
+
- **Batch Operations**: Support for concurrent operations
|
|
312
|
+
|
|
313
|
+
### Compatibility
|
|
314
|
+
|
|
315
|
+
- **Python Versions**: 3.8, 3.9, 3.10, 3.11, 3.12
|
|
316
|
+
- **Framework Support**: FastAPI, Django, Flask, and custom applications
|
|
317
|
+
- **Redis Versions**: Compatible with Redis 5.0+
|
|
318
|
+
- **HTTP Clients**: Uses httpx for modern async HTTP support
|
|
319
|
+
|
|
320
|
+
### Migration
|
|
321
|
+
|
|
322
|
+
- **From Keycloak**: Seamless migration from direct Keycloak integration
|
|
323
|
+
- **Backward Compatibility**: Maintains existing API patterns
|
|
324
|
+
- **Configuration**: Simple configuration migration
|
|
325
|
+
- **Testing**: Comprehensive migration testing support
|
|
326
|
+
|
|
327
|
+
---
|
|
328
|
+
|
|
329
|
+
## Future Releases
|
|
330
|
+
|
|
331
|
+
### Planned Features
|
|
332
|
+
|
|
333
|
+
- **WebSocket Support**: Real-time authentication updates
|
|
334
|
+
- **Metrics Integration**: Prometheus and OpenTelemetry support
|
|
335
|
+
- **Advanced Caching**: Cache invalidation strategies
|
|
336
|
+
- **Multi-Controller Support**: Load balancing across multiple controllers
|
|
337
|
+
- **SDK Extensions**: Framework-specific SDK extensions
|
|
338
|
+
|
|
339
|
+
### Roadmap
|
|
340
|
+
|
|
341
|
+
- **v1.1.0**: WebSocket support and real-time updates
|
|
342
|
+
- **v1.2.0**: Advanced metrics and monitoring
|
|
343
|
+
- **v2.0.0**: Multi-controller support and load balancing
|
|
344
|
+
- **v2.1.0**: Framework-specific SDK extensions
|
|
345
|
+
|
|
346
|
+
---
|
|
347
|
+
|
|
348
|
+
For more information about the MisoClient SDK, visit:
|
|
349
|
+
- [Documentation](https://docs.aifabrix.ai/miso-client-python)
|
|
350
|
+
- [GitHub Repository](https://github.com/aifabrix/miso-client-python)
|
|
351
|
+
- [Issue Tracker](https://github.com/aifabrix/miso-client-python/issues)
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.4
|
|
2
2
|
Name: miso-client
|
|
3
|
-
Version: 0.
|
|
3
|
+
Version: 0.4.0
|
|
4
4
|
Summary: Python client SDK for AI Fabrix authentication, authorization, and logging
|
|
5
5
|
Home-page: https://github.com/aifabrix/miso-client-python
|
|
6
6
|
Author: AI Fabrix Team
|
|
@@ -80,10 +80,13 @@ The **AI Fabrix Miso Client SDK** provides authentication, authorization, and lo
|
|
|
80
80
|
### 📊 Compliance & Audit
|
|
81
81
|
|
|
82
82
|
**ISO 27001 Compliance**
|
|
83
|
-
- Comprehensive audit trails for all user actions
|
|
83
|
+
- Comprehensive audit trails for all user actions and HTTP requests
|
|
84
|
+
- Automatic data masking for all sensitive information in logs
|
|
85
|
+
- HTTP request/response audit logging with masked sensitive data
|
|
84
86
|
- Data access logging and monitoring
|
|
85
87
|
- Security event tracking
|
|
86
88
|
- Accountability and non-repudiation
|
|
89
|
+
- Configurable sensitive fields via JSON configuration
|
|
87
90
|
|
|
88
91
|
**Regulatory Compliance**
|
|
89
92
|
- GDPR-ready data protection
|
|
@@ -134,9 +137,13 @@ The **AI Fabrix Miso Client SDK** provides authentication, authorization, and lo
|
|
|
134
137
|
|
|
135
138
|
**Observability**
|
|
136
139
|
- Centralized logging with correlation IDs
|
|
140
|
+
- Automatic HTTP request/response audit logging (ISO 27001 compliant)
|
|
141
|
+
- Debug logging with detailed request/response information (when `log_level='debug'`)
|
|
137
142
|
- Performance tracking and metrics
|
|
138
143
|
- Error tracking and debugging
|
|
139
144
|
- Health monitoring
|
|
145
|
+
- Automatic data masking for sensitive information in logs
|
|
146
|
+
- Configurable sensitive fields via JSON configuration
|
|
140
147
|
|
|
141
148
|
---
|
|
142
149
|
|
|
@@ -262,7 +269,7 @@ if is_admin:
|
|
|
262
269
|
|
|
263
270
|
### Step 5: Activate Logging
|
|
264
271
|
|
|
265
|
-
**What happens:** Application logs are sent to the Miso Controller with client token authentication.
|
|
272
|
+
**What happens:** Application logs are sent to the Miso Controller with client token authentication. All HTTP requests are automatically audited with ISO 27001 compliant data masking.
|
|
266
273
|
|
|
267
274
|
```python
|
|
268
275
|
from miso_client import MisoClient, load_config
|
|
@@ -278,10 +285,17 @@ user = await client.get_user(token)
|
|
|
278
285
|
await client.log.info('User accessed dashboard', {'userId': user.id if user else None})
|
|
279
286
|
await client.log.error('Operation failed', {'error': str(err)})
|
|
280
287
|
await client.log.warn('Unusual activity', {'details': '...'})
|
|
288
|
+
|
|
289
|
+
# HTTP requests are automatically audited
|
|
290
|
+
# All sensitive data is automatically masked before logging
|
|
291
|
+
result = await client.http_client.get('/api/users')
|
|
292
|
+
# This automatically creates an audit log: http.request.GET with masked sensitive data
|
|
281
293
|
```
|
|
282
294
|
|
|
283
295
|
**What happens to logs?** They're sent to the Miso Controller for centralized monitoring and analysis. Client token is automatically included.
|
|
284
296
|
|
|
297
|
+
**ISO 27001 Compliance:** All HTTP requests are automatically audited with sensitive data masked. Set `log_level='debug'` to enable detailed request/response logging (all sensitive data is still masked).
|
|
298
|
+
|
|
285
299
|
→ [Complete logging example](examples/step-5-logging.py)
|
|
286
300
|
→ [Logging Reference](docs/api-reference.md#logger-service)
|
|
287
301
|
|
|
@@ -366,6 +380,40 @@ ENCRYPTION_KEY=your-32-byte-encryption-key
|
|
|
366
380
|
|
|
367
381
|
---
|
|
368
382
|
|
|
383
|
+
### Testing with API Key
|
|
384
|
+
|
|
385
|
+
**What happens:** When `API_KEY` is set in your `.env` file, you can authenticate requests using the API key as a bearer token, bypassing OAuth2 authentication. This is useful for testing without setting up Keycloak.
|
|
386
|
+
|
|
387
|
+
```python
|
|
388
|
+
from miso_client import MisoClient, load_config
|
|
389
|
+
|
|
390
|
+
client = MisoClient(load_config())
|
|
391
|
+
await client.initialize()
|
|
392
|
+
|
|
393
|
+
# Use API_KEY as bearer token (for testing only)
|
|
394
|
+
api_key_token = "your-api-key-from-env"
|
|
395
|
+
is_valid = await client.validate_token(api_key_token)
|
|
396
|
+
# Returns True if token matches API_KEY from .env
|
|
397
|
+
|
|
398
|
+
user = await client.get_user(api_key_token)
|
|
399
|
+
# Returns None (API key auth doesn't provide user info)
|
|
400
|
+
```
|
|
401
|
+
|
|
402
|
+
**Configuration:**
|
|
403
|
+
|
|
404
|
+
```bash
|
|
405
|
+
# Add to .env for testing
|
|
406
|
+
API_KEY=your-test-api-key-here
|
|
407
|
+
```
|
|
408
|
+
|
|
409
|
+
**Important:**
|
|
410
|
+
- API_KEY authentication bypasses OAuth2 validation completely
|
|
411
|
+
- User information methods (`get_user()`, `get_user_info()`) return `None` when using API_KEY
|
|
412
|
+
- Token validation returns `True` if the bearer token matches the configured `API_KEY`
|
|
413
|
+
- This feature is intended for testing and development only
|
|
414
|
+
|
|
415
|
+
---
|
|
416
|
+
|
|
369
417
|
## 🔧 Configuration
|
|
370
418
|
|
|
371
419
|
```python
|
|
@@ -380,6 +428,8 @@ config = MisoClientConfig(
|
|
|
380
428
|
port=6379,
|
|
381
429
|
),
|
|
382
430
|
log_level="info", # Optional: 'debug' | 'info' | 'warn' | 'error'
|
|
431
|
+
# Set to 'debug' for detailed HTTP request/response logging
|
|
432
|
+
api_key="your-test-api-key", # Optional: API key for testing (bypasses OAuth2)
|
|
383
433
|
cache={ # Optional: Cache TTL settings
|
|
384
434
|
"role_ttl": 900, # Role cache TTL (default: 900s)
|
|
385
435
|
"permission_ttl": 900, # Permission cache TTL (default: 900s)
|
|
@@ -389,6 +439,18 @@ config = MisoClientConfig(
|
|
|
389
439
|
|
|
390
440
|
**Recommended:** Use `load_config()` to load from `.env` file automatically.
|
|
391
441
|
|
|
442
|
+
**ISO 27001 Data Masking Configuration:**
|
|
443
|
+
|
|
444
|
+
Sensitive fields are configured via `miso_client/utils/sensitive_fields_config.json`. You can customize this by:
|
|
445
|
+
|
|
446
|
+
1. Setting `MISO_SENSITIVE_FIELDS_CONFIG` environment variable to point to a custom JSON file
|
|
447
|
+
2. Using `DataMasker.set_config_path()` to set a custom path programmatically
|
|
448
|
+
|
|
449
|
+
The default configuration includes ISO 27001 compliant sensitive fields:
|
|
450
|
+
- Authentication: password, token, secret, key, auth, authorization
|
|
451
|
+
- PII: ssn, creditcard, cc, cvv, pin, otp
|
|
452
|
+
- Security: apikey, accesstoken, refreshtoken, privatekey, secretkey, cookie, session
|
|
453
|
+
|
|
392
454
|
→ [Complete Configuration Reference](docs/configuration.md)
|
|
393
455
|
|
|
394
456
|
---
|
|
@@ -413,6 +475,28 @@ The SDK consists of five core services:
|
|
|
413
475
|
- **LoggerService** - Centralized logging with API key authentication
|
|
414
476
|
- **RedisService** - Caching and queue management (optional)
|
|
415
477
|
|
|
478
|
+
### HTTP Client Architecture
|
|
479
|
+
|
|
480
|
+
The SDK uses a two-layer HTTP client architecture for ISO 27001 compliance:
|
|
481
|
+
|
|
482
|
+
- **InternalHttpClient** - Core HTTP functionality with automatic client token management (internal)
|
|
483
|
+
- **HttpClient** - Public wrapper that adds automatic ISO 27001 compliant audit and debug logging
|
|
484
|
+
|
|
485
|
+
**Features:**
|
|
486
|
+
- Automatic audit logging for all HTTP requests (`http.request.{METHOD}`)
|
|
487
|
+
- Debug logging when `log_level === 'debug'` with detailed request/response information
|
|
488
|
+
- Automatic data masking using `DataMasker` before logging (ISO 27001 compliant)
|
|
489
|
+
- Sensitive endpoints (`/api/logs`, `/api/auth/token`) are excluded from audit logging to prevent infinite loops
|
|
490
|
+
- All sensitive data (headers, bodies, query params) is automatically masked before logging
|
|
491
|
+
|
|
492
|
+
**ISO 27001 Compliance:**
|
|
493
|
+
- All request headers are masked (Authorization, x-client-token, Cookie, etc.)
|
|
494
|
+
- All request bodies are recursively masked for sensitive fields (password, token, secret, SSN, etc.)
|
|
495
|
+
- All response bodies are masked (limited to first 1000 characters)
|
|
496
|
+
- Query parameters are automatically masked
|
|
497
|
+
- Error messages are masked if they contain sensitive data
|
|
498
|
+
- Sensitive fields configuration can be customized via `sensitive_fields_config.json`
|
|
499
|
+
|
|
416
500
|
→ [Architecture Details](docs/api-reference.md#architecture)
|
|
417
501
|
|
|
418
502
|
---
|
|
@@ -450,6 +534,83 @@ The SDK consists of five core services:
|
|
|
450
534
|
- [Flask Decorators](docs/examples.md#flask-decorators) - Decorator-based auth
|
|
451
535
|
- [Error Handling](docs/examples.md#error-handling) - Best practices
|
|
452
536
|
|
|
537
|
+
---
|
|
538
|
+
|
|
539
|
+
### Structured Error Responses
|
|
540
|
+
|
|
541
|
+
**What happens:** The SDK automatically parses structured error responses from the API (RFC 7807-style format) and makes them available through the `MisoClientError` exception.
|
|
542
|
+
|
|
543
|
+
```python
|
|
544
|
+
from miso_client import MisoClient, MisoClientError, ErrorResponse, load_config
|
|
545
|
+
|
|
546
|
+
client = MisoClient(load_config())
|
|
547
|
+
await client.initialize()
|
|
548
|
+
|
|
549
|
+
try:
|
|
550
|
+
result = await client.http_client.get("/api/some-endpoint")
|
|
551
|
+
except MisoClientError as e:
|
|
552
|
+
# Check if structured error response is available
|
|
553
|
+
if e.error_response:
|
|
554
|
+
print(f"Error Type: {e.error_response.type}")
|
|
555
|
+
print(f"Error Title: {e.error_response.title}")
|
|
556
|
+
print(f"Status Code: {e.error_response.statusCode}")
|
|
557
|
+
print(f"Errors: {e.error_response.errors}")
|
|
558
|
+
print(f"Instance: {e.error_response.instance}")
|
|
559
|
+
else:
|
|
560
|
+
# Fallback to traditional error handling
|
|
561
|
+
print(f"Error: {e.message}")
|
|
562
|
+
print(f"Status Code: {e.status_code}")
|
|
563
|
+
print(f"Error Body: {e.error_body}")
|
|
564
|
+
```
|
|
565
|
+
|
|
566
|
+
**Error Response Structure:**
|
|
567
|
+
|
|
568
|
+
The `ErrorResponse` model follows RFC 7807-style format:
|
|
569
|
+
|
|
570
|
+
```json
|
|
571
|
+
{
|
|
572
|
+
"errors": [
|
|
573
|
+
"The user has provided input that the browser is unable to convert.",
|
|
574
|
+
"There are multiple rows in the database for the same value"
|
|
575
|
+
],
|
|
576
|
+
"type": "/Errors/Bad Input",
|
|
577
|
+
"title": "Bad Request",
|
|
578
|
+
"statusCode": 400,
|
|
579
|
+
"instance": "/OpenApi/rest/Xzy"
|
|
580
|
+
}
|
|
581
|
+
```
|
|
582
|
+
|
|
583
|
+
**Features:**
|
|
584
|
+
|
|
585
|
+
- **Automatic Parsing**: Structured error responses are automatically parsed from HTTP responses
|
|
586
|
+
- **Backward Compatible**: Falls back to traditional error handling when structured format is not available
|
|
587
|
+
- **Type Safety**: Full type hints with Pydantic models for reliable error handling
|
|
588
|
+
- **Generic Interface**: `ErrorResponse` model can be reused across different applications
|
|
589
|
+
- **Instance URI**: Automatically extracted from request URL if not provided in response
|
|
590
|
+
|
|
591
|
+
**Using ErrorResponse directly:**
|
|
592
|
+
|
|
593
|
+
```python
|
|
594
|
+
from miso_client import ErrorResponse
|
|
595
|
+
|
|
596
|
+
# Create ErrorResponse from dict
|
|
597
|
+
error_data = {
|
|
598
|
+
"errors": ["Validation failed"],
|
|
599
|
+
"type": "/Errors/Validation",
|
|
600
|
+
"title": "Validation Error",
|
|
601
|
+
"statusCode": 422,
|
|
602
|
+
"instance": "/api/endpoint"
|
|
603
|
+
}
|
|
604
|
+
error_response = ErrorResponse(**error_data)
|
|
605
|
+
|
|
606
|
+
# Access fields
|
|
607
|
+
print(error_response.errors) # ["Validation failed"]
|
|
608
|
+
print(error_response.type) # "/Errors/Validation"
|
|
609
|
+
print(error_response.title) # "Validation Error"
|
|
610
|
+
print(error_response.statusCode) # 422
|
|
611
|
+
print(error_response.instance) # "/api/endpoint"
|
|
612
|
+
```
|
|
613
|
+
|
|
453
614
|
### Common Tasks
|
|
454
615
|
|
|
455
616
|
**Add authentication middleware (FastAPI):**
|
|
@@ -490,6 +651,7 @@ MISO_CONTROLLER_URL=http://localhost:3000
|
|
|
490
651
|
REDIS_HOST=localhost
|
|
491
652
|
REDIS_PORT=6379
|
|
492
653
|
MISO_LOG_LEVEL=info
|
|
654
|
+
API_KEY=your-test-api-key # Optional: For testing (bypasses OAuth2)
|
|
493
655
|
```
|
|
494
656
|
|
|
495
657
|
---
|