add stories
This commit is contained in:
+24
-24
@@ -16,43 +16,43 @@
|
||||
"author": "Task Venture Capital GmbH",
|
||||
"license": "MIT",
|
||||
"dependencies": {
|
||||
"@api.global/typedrequest": "^3.0.32",
|
||||
"@api.global/typedrequest": "^3.1.10",
|
||||
"@api.global/typedrequest-interfaces": "^3.0.19",
|
||||
"@api.global/typedserver": "^3.0.51",
|
||||
"@api.global/typedserver": "^3.0.80",
|
||||
"@api.global/typedsocket": "^3.0.1",
|
||||
"@consentsoftware_private/catalog": "^1.0.73",
|
||||
"@design.estate/dees-catalog": "^1.2.0",
|
||||
"@design.estate/dees-domtools": "^2.0.64",
|
||||
"@design.estate/dees-element": "^2.0.39",
|
||||
"@push.rocks/lik": "^6.0.15",
|
||||
"@push.rocks/qenv": "^6.0.5",
|
||||
"@push.rocks/smartdata": "^5.2.10",
|
||||
"@design.estate/dees-catalog": "^2.0.0",
|
||||
"@design.estate/dees-domtools": "^2.3.6",
|
||||
"@design.estate/dees-element": "^2.1.3",
|
||||
"@push.rocks/lik": "^6.2.2",
|
||||
"@push.rocks/qenv": "^6.1.3",
|
||||
"@push.rocks/smartdata": "^7.0.14",
|
||||
"@push.rocks/smartdelay": "^3.0.5",
|
||||
"@push.rocks/smarthash": "^3.0.4",
|
||||
"@push.rocks/smartjson": "^5.0.20",
|
||||
"@push.rocks/smarthash": "^3.2.6",
|
||||
"@push.rocks/smartjson": "^5.2.0",
|
||||
"@push.rocks/smartjwt": "^2.2.1",
|
||||
"@push.rocks/smartlog": "^3.0.7",
|
||||
"@push.rocks/smartmail": "^1.0.24",
|
||||
"@push.rocks/smartpath": "^5.0.5",
|
||||
"@push.rocks/smartpromise": "^4.0.4",
|
||||
"@push.rocks/smartrx": "^3.0.7",
|
||||
"@push.rocks/smartstate": "^2.0.19",
|
||||
"@push.rocks/smarttime": "^4.0.8",
|
||||
"@push.rocks/smartlog": "^3.1.10",
|
||||
"@push.rocks/smartmail": "^2.2.0",
|
||||
"@push.rocks/smartpath": "^6.0.0",
|
||||
"@push.rocks/smartpromise": "^4.2.3",
|
||||
"@push.rocks/smartrx": "^3.0.10",
|
||||
"@push.rocks/smartstate": "^2.0.27",
|
||||
"@push.rocks/smarttime": "^4.1.1",
|
||||
"@push.rocks/smartunique": "^3.0.9",
|
||||
"@push.rocks/smarturl": "^3.1.0",
|
||||
"@push.rocks/taskbuffer": "^3.1.7",
|
||||
"@push.rocks/taskbuffer": "^3.4.0",
|
||||
"@push.rocks/webjwt": "^1.0.9",
|
||||
"@push.rocks/websetup": "^3.0.15",
|
||||
"@push.rocks/webstore": "^2.0.20",
|
||||
"@serve.zone/platformclient": "^1.1.2",
|
||||
"@tsclass/tsclass": "^4.1.2",
|
||||
"@uptime.link/webwidget": "^1.1.2"
|
||||
"@tsclass/tsclass": "^9.3.0",
|
||||
"@uptime.link/webwidget": "^1.2.3"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@git.zone/tsbuild": "^2.1.17",
|
||||
"@git.zone/tsbundle": "^2.0.3",
|
||||
"@git.zone/tsrun": "^1.2.8",
|
||||
"@git.zone/tswatch": "^2.0.1",
|
||||
"@git.zone/tsbuild": "^3.1.2",
|
||||
"@git.zone/tsbundle": "^2.6.1",
|
||||
"@git.zone/tsrun": "^2.0.0",
|
||||
"@git.zone/tswatch": "^2.2.1",
|
||||
"@push.rocks/projectinfo": "^5.0.1",
|
||||
"@types/node": "^22.7.4"
|
||||
},
|
||||
|
||||
Generated
+5344
-3561
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,87 @@
|
||||
# idp.global User Stories
|
||||
|
||||
This directory contains user stories for the idp.global Identity Provider platform, organized by persona.
|
||||
|
||||
## Directory Structure
|
||||
|
||||
```
|
||||
stories/
|
||||
├── end-user/ # Stories for regular users (8)
|
||||
├── organization-owner/ # Stories for organization admins (8)
|
||||
├── developer/ # Stories for API/SDK consumers (7)
|
||||
└── admin/ # Stories for platform administrators (7)
|
||||
```
|
||||
|
||||
## Story Index
|
||||
|
||||
### End User (EU)
|
||||
| ID | Title | Priority | Source |
|
||||
|----|-------|----------|--------|
|
||||
| EU-001 | [Multi-Device Login Sessions](end-user/EU-001-multi-device-login.md) | High | TODO |
|
||||
| EU-002 | [Complete Password Reset Flow](end-user/EU-002-password-reset.md) | Critical | Incomplete |
|
||||
| EU-003 | [View and Manage Logged-in Devices](end-user/EU-003-device-management.md) | Medium | TODO |
|
||||
| EU-004 | [Enable Two-Factor Authentication](end-user/EU-004-two-factor-auth.md) | High | New |
|
||||
| EU-005 | [Login with Social Providers](end-user/EU-005-social-login.md) | Medium | New |
|
||||
| EU-006 | [Delete My Account](end-user/EU-006-account-deletion.md) | Medium | New |
|
||||
| EU-007 | [View Login History](end-user/EU-007-session-history.md) | Low | New |
|
||||
| EU-008 | [Upload Profile Avatar](end-user/EU-008-profile-avatar.md) | Low | New |
|
||||
|
||||
### Organization Owner (ORG)
|
||||
| ID | Title | Priority | Source |
|
||||
|----|-------|----------|--------|
|
||||
| ORG-001 | [Sync Billing Plans with Users](organization-owner/ORG-001-billing-sync.md) | High | TODO |
|
||||
| ORG-002 | [Invite and Manage Team Members](organization-owner/ORG-002-member-management.md) | Critical | New |
|
||||
| ORG-003 | [Assign Roles to Members](organization-owner/ORG-003-role-assignment.md) | High | Partial |
|
||||
| ORG-004 | [Customize Organization Branding](organization-owner/ORG-004-org-branding.md) | Medium | New |
|
||||
| ORG-005 | [View Organization Usage Analytics](organization-owner/ORG-005-usage-analytics.md) | Medium | New |
|
||||
| ORG-006 | [Configure SSO for Organization](organization-owner/ORG-006-sso-config.md) | High | New |
|
||||
| ORG-007 | [View Organization Audit Logs](organization-owner/ORG-007-audit-logs.md) | Medium | New |
|
||||
| ORG-008 | [Manage Subscription and Billing](organization-owner/ORG-008-subscription-management.md) | Medium | Enhance |
|
||||
|
||||
### Developer (DEV)
|
||||
| ID | Title | Priority | Source |
|
||||
|----|-------|----------|--------|
|
||||
| DEV-001 | [Create and Manage API Tokens](developer/DEV-001-api-token-management.md) | High | Partial |
|
||||
| DEV-002 | [Comprehensive SDK Documentation](developer/DEV-002-sdk-documentation.md) | High | New |
|
||||
| DEV-003 | [Configure Webhook Notifications](developer/DEV-003-webhook-events.md) | Medium | New |
|
||||
| DEV-004 | [Proper App ID Initialization](developer/DEV-004-app-id-setup.md) | High | TODO |
|
||||
| DEV-005 | [Register OAuth Client App](developer/DEV-005-oauth-client.md) | Medium | New |
|
||||
| DEV-006 | [Understand API Rate Limits](developer/DEV-006-rate-limiting.md) | Low | New |
|
||||
| DEV-007 | [Validate JWTs in My Application](developer/DEV-007-jwt-validation.md) | Medium | Enhance |
|
||||
|
||||
### Platform Admin (ADM)
|
||||
| ID | Title | Priority | Source |
|
||||
|----|-------|----------|--------|
|
||||
| ADM-001 | [Secure JWT Endpoints with Backend Token](admin/ADM-001-backend-token-security.md) | Critical | TODO |
|
||||
| ADM-002 | [Suspend and Delete Users](admin/ADM-002-user-suspension.md) | High | Partial |
|
||||
| ADM-003 | [Platform-wide Audit Logging](admin/ADM-003-global-audit-log.md) | High | New |
|
||||
| ADM-004 | [Customize Email Templates](admin/ADM-004-email-templates.md) | Medium | New |
|
||||
| ADM-005 | [Security Monitoring Dashboard](admin/ADM-005-security-dashboard.md) | Medium | New |
|
||||
| ADM-006 | [Impersonate Users for Support](admin/ADM-006-user-impersonation.md) | Low | New |
|
||||
| ADM-007 | [Manage JWT Blocklist](admin/ADM-007-blocklist-management.md) | Medium | Enhance |
|
||||
|
||||
## Priority Summary
|
||||
|
||||
| Priority | Count | Stories |
|
||||
|----------|-------|---------|
|
||||
| Critical | 3 | EU-002, ORG-002, ADM-001 |
|
||||
| High | 10 | EU-001, EU-004, ORG-001, ORG-003, ORG-006, DEV-001, DEV-002, DEV-004, ADM-002, ADM-003 |
|
||||
| Medium | 12 | EU-003, EU-005, EU-006, ORG-004, ORG-005, ORG-007, ORG-008, DEV-003, DEV-005, DEV-007, ADM-004, ADM-005, ADM-007 |
|
||||
| Low | 5 | EU-007, EU-008, DEV-006, ADM-006 |
|
||||
|
||||
## Source Legend
|
||||
|
||||
- **TODO**: Derived from TODO comments in codebase
|
||||
- **Incomplete**: Feature exists but implementation is incomplete
|
||||
- **Partial**: Infrastructure exists, needs completion
|
||||
- **Enhance**: Feature works, could be improved
|
||||
- **New**: New feature not currently in codebase
|
||||
|
||||
## Related Code References
|
||||
|
||||
Stories derived from code TODOs reference these files:
|
||||
- `ts/reception/classes.jwt.ts:39`
|
||||
- `ts/reception/classes.jwtmanager.ts:40,52`
|
||||
- `ts/reception/classes.loginsessionmanager.ts:229-238,256`
|
||||
- `ts/reception/classes.billingplan.ts:16`
|
||||
- `ts_idpclient/classes.idpclient.ts:30`
|
||||
@@ -0,0 +1,28 @@
|
||||
# Secure JWT Endpoints with Backend Token
|
||||
|
||||
**ID:** ADM-001
|
||||
**Priority:** Critical
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want JWT-related endpoints to be secured with backend token validation so that only authorized services can access sensitive security operations.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Public key endpoint requires valid backend token
|
||||
- [ ] JWT blocklist endpoint requires valid backend token
|
||||
- [ ] Backend tokens are securely generated and distributed
|
||||
- [ ] Token validation is performed on every request
|
||||
- [ ] Invalid/missing token returns 401 Unauthorized
|
||||
- [ ] Tokens can be rotated without service interruption
|
||||
- [ ] Audit log for all backend token usage
|
||||
|
||||
## Technical Notes
|
||||
- Two TODOs exist for backend token validation in JwtManager
|
||||
- `getPublicKeyForValidation` and `pushOrGetJwtIdBlocklist` need protection
|
||||
- Backend token should be separate from user JWT
|
||||
- Consider service-to-service authentication pattern
|
||||
- Environment variable for backend token configuration
|
||||
|
||||
## Related TODOs
|
||||
- `ts/reception/classes.jwtmanager.ts:40` - `// TODO control backend token`
|
||||
- `ts/reception/classes.jwtmanager.ts:52` - `// TODO control backend token`
|
||||
@@ -0,0 +1,28 @@
|
||||
# Suspend and Delete Users
|
||||
|
||||
**ID:** ADM-002
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to suspend and delete user accounts so that I can handle policy violations, security incidents, and account removal requests.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Admin can search for users by email, name, or ID
|
||||
- [ ] Admin can suspend a user account with reason
|
||||
- [ ] Suspended users cannot log in
|
||||
- [ ] Suspended users' active sessions are invalidated
|
||||
- [ ] Admin can unsuspend accounts
|
||||
- [ ] Admin can permanently delete suspended accounts
|
||||
- [ ] Deletion removes all user data (GDPR compliance)
|
||||
- [ ] Audit log for all suspension/deletion actions
|
||||
|
||||
## Technical Notes
|
||||
- `suspendUser` and `deleteSuspendedUser` endpoints exist
|
||||
- Need admin UI for user management
|
||||
- Consider soft delete with retention period
|
||||
- Handle organization ownership before deletion
|
||||
- Email notification to user on suspension
|
||||
|
||||
## Related TODOs
|
||||
- Partial implementation in UserManager
|
||||
@@ -0,0 +1,28 @@
|
||||
# Platform-wide Audit Logging
|
||||
|
||||
**ID:** ADM-003
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to view platform-wide audit logs so that I can monitor security events, investigate incidents, and demonstrate compliance.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Log all authentication events (login, logout, failed attempts)
|
||||
- [ ] Log all administrative actions (user changes, config changes)
|
||||
- [ ] Log all security events (password changes, 2FA changes, token revocations)
|
||||
- [ ] Searchable log interface with filters
|
||||
- [ ] Real-time log streaming for monitoring
|
||||
- [ ] Export logs in standard formats (JSON, CSV, CEF)
|
||||
- [ ] Log retention configuration
|
||||
- [ ] Integration with external SIEM systems
|
||||
|
||||
## Technical Notes
|
||||
- Separate from organization audit logs (ORG-007)
|
||||
- Platform-wide view across all organizations
|
||||
- Consider ELK stack or similar for log aggregation
|
||||
- Structured logging format for parsing
|
||||
- Compliance: SOC 2, ISO 27001, GDPR audit requirements
|
||||
|
||||
## Related TODOs
|
||||
- New feature - platform security requirement
|
||||
@@ -0,0 +1,28 @@
|
||||
# Customize Email Templates
|
||||
|
||||
**ID:** ADM-004
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to customize email templates so that all system emails match our branding and communication style.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Edit templates for: registration, password reset, login verification, welcome
|
||||
- [ ] Rich text editor for template content
|
||||
- [ ] Variable placeholders ({{userName}}, {{resetLink}}, etc.)
|
||||
- [ ] Preview emails before saving
|
||||
- [ ] Send test emails to verify
|
||||
- [ ] Localization support for multiple languages
|
||||
- [ ] Reset to default template option
|
||||
- [ ] Version history for templates
|
||||
|
||||
## Technical Notes
|
||||
- ReceptionMailer handles email sending
|
||||
- Currently uses hardcoded or simple templates
|
||||
- Consider template engine (Handlebars, Mjml for responsive)
|
||||
- Store templates in database for dynamic updates
|
||||
- Support HTML and plain text versions
|
||||
|
||||
## Related TODOs
|
||||
- New feature - enhance ReceptionMailer
|
||||
@@ -0,0 +1,28 @@
|
||||
# Security Monitoring Dashboard
|
||||
|
||||
**ID:** ADM-005
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want a security monitoring dashboard so that I can quickly identify and respond to potential security threats.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Real-time metrics: active sessions, login rate, failure rate
|
||||
- [ ] Anomaly detection alerts (unusual login patterns)
|
||||
- [ ] Geographic map of login locations
|
||||
- [ ] Failed login attempt heatmap
|
||||
- [ ] Blocked JWT/token statistics
|
||||
- [ ] Suspicious activity indicators
|
||||
- [ ] Configurable alert thresholds
|
||||
- [ ] Integration with alerting systems (PagerDuty, Slack)
|
||||
|
||||
## Technical Notes
|
||||
- Aggregate metrics from login events
|
||||
- Real-time updates via WebSocket
|
||||
- Consider time-series database for metrics
|
||||
- Machine learning for anomaly detection (future)
|
||||
- Alert rules engine for custom notifications
|
||||
|
||||
## Related TODOs
|
||||
- New feature - security operations
|
||||
@@ -0,0 +1,28 @@
|
||||
# Impersonate Users for Support
|
||||
|
||||
**ID:** ADM-006
|
||||
**Priority:** Low
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to temporarily impersonate a user so that I can troubleshoot issues they're experiencing without asking for their credentials.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Admin can initiate impersonation session for any user
|
||||
- [ ] Impersonation requires confirmation and reason
|
||||
- [ ] Clear visual indicator when in impersonation mode
|
||||
- [ ] Admin can end impersonation and return to their session
|
||||
- [ ] All actions during impersonation are logged
|
||||
- [ ] User is optionally notified of impersonation
|
||||
- [ ] Impersonation sessions have time limit
|
||||
- [ ] Cannot impersonate other admins without super-admin
|
||||
|
||||
## Technical Notes
|
||||
- Special JWT claim to indicate impersonation
|
||||
- Original admin identity preserved in token
|
||||
- Audit log must capture both admin and impersonated user
|
||||
- Consider "read-only" impersonation mode
|
||||
- Security review required before implementation
|
||||
|
||||
## Related TODOs
|
||||
- New feature - support tooling
|
||||
@@ -0,0 +1,28 @@
|
||||
# Manage JWT Blocklist
|
||||
|
||||
**ID:** ADM-007
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a platform administrator, I want to view and manage the JWT blocklist so that I can revoke tokens during security incidents and verify that revocations are working.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] View all blocked JWT IDs with metadata
|
||||
- [ ] Search blocklist by JWT ID or user
|
||||
- [ ] Manually add JWTs to blocklist
|
||||
- [ ] View reason for each blocklist entry
|
||||
- [ ] Blocklist entries show expiration (when they can be removed)
|
||||
- [ ] Bulk revoke all tokens for a user
|
||||
- [ ] Bulk revoke all tokens for an organization
|
||||
- [ ] Automatic cleanup of expired blocklist entries
|
||||
|
||||
## Technical Notes
|
||||
- JwtManager has `blockedJwtIdList` infrastructure
|
||||
- `pushOrGetJwtIdBlocklist` endpoint exists
|
||||
- Need admin UI for blocklist management
|
||||
- ReceptionHousekeeping could handle cleanup
|
||||
- Consider Redis for high-performance blocklist checks
|
||||
|
||||
## Related TODOs
|
||||
- Enhancement to existing blocklist infrastructure
|
||||
@@ -0,0 +1,28 @@
|
||||
# Create and Manage API Tokens
|
||||
|
||||
**ID:** DEV-001
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to create and manage API tokens so that I can integrate my applications with the identity provider programmatically.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Developer can create new API tokens with custom names
|
||||
- [ ] Token is shown once at creation (cannot be retrieved later)
|
||||
- [ ] Developer can set token expiration (or no expiration)
|
||||
- [ ] Developer can set token scopes/permissions
|
||||
- [ ] List all tokens with creation date and last used
|
||||
- [ ] Revoke individual tokens
|
||||
- [ ] Revoke all tokens at once
|
||||
- [ ] Rate limiting information shown per token
|
||||
|
||||
## Technical Notes
|
||||
- ApiTokenManager exists with basic infrastructure
|
||||
- `loginWithApiToken` endpoint available
|
||||
- Need UI for token management (currently backend only)
|
||||
- Tokens should be hashed before storage (show once)
|
||||
- Consider token prefixes for easy identification (idp_...)
|
||||
|
||||
## Related TODOs
|
||||
- Partial implementation in ApiTokenManager
|
||||
@@ -0,0 +1,28 @@
|
||||
# Comprehensive SDK Documentation
|
||||
|
||||
**ID:** DEV-002
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want comprehensive documentation for the IDP client SDK so that I can integrate authentication into my applications quickly and correctly.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Getting started guide with installation and setup
|
||||
- [ ] Authentication flow explanations with diagrams
|
||||
- [ ] API reference for all client methods
|
||||
- [ ] Code examples for common use cases
|
||||
- [ ] TypeScript type definitions documented
|
||||
- [ ] Error handling guide with error codes
|
||||
- [ ] Migration guides for version upgrades
|
||||
- [ ] Interactive API playground/sandbox
|
||||
|
||||
## Technical Notes
|
||||
- `ts_idpclient/` contains the client SDK
|
||||
- README.md has basic usage but needs expansion
|
||||
- Generate API docs from TypeScript using TypeDoc
|
||||
- Host documentation on dedicated site or GitHub pages
|
||||
- Consider OpenAPI/Swagger spec for REST endpoints
|
||||
|
||||
## Related TODOs
|
||||
- New feature - documentation enhancement
|
||||
@@ -0,0 +1,28 @@
|
||||
# Configure Webhook Notifications
|
||||
|
||||
**ID:** DEV-003
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to configure webhooks so that my application is notified in real-time when authentication events occur.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Register webhook endpoints with URL and secret
|
||||
- [ ] Select which events to subscribe to
|
||||
- [ ] Events include: user.created, user.login, user.logout, org.member.added, etc.
|
||||
- [ ] Webhook payloads include event type, timestamp, and relevant data
|
||||
- [ ] Signature verification using shared secret (HMAC)
|
||||
- [ ] Retry logic for failed deliveries (exponential backoff)
|
||||
- [ ] Webhook delivery logs with success/failure status
|
||||
- [ ] Test webhook button to send sample event
|
||||
|
||||
## Technical Notes
|
||||
- Create Webhook model with URL, secret, events, and status
|
||||
- Queue webhook deliveries for reliability (consider bull/bullmq)
|
||||
- Sign payloads with HMAC-SHA256
|
||||
- Timeout for webhook delivery (10 seconds)
|
||||
- Dashboard for delivery monitoring and debugging
|
||||
|
||||
## Related TODOs
|
||||
- New feature - event-driven integration
|
||||
@@ -0,0 +1,28 @@
|
||||
# Proper App ID Initialization
|
||||
|
||||
**ID:** DEV-004
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to properly register my application with a unique App ID so that the identity provider can identify and configure my app correctly.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Developer can register new applications
|
||||
- [ ] Each app gets unique App ID and App Secret
|
||||
- [ ] Configure allowed redirect URIs per app
|
||||
- [ ] Configure allowed origins (CORS) per app
|
||||
- [ ] App-specific settings (token expiry, etc.)
|
||||
- [ ] View app analytics (logins per app)
|
||||
- [ ] Regenerate app secret if compromised
|
||||
- [ ] Delete/deactivate applications
|
||||
|
||||
## Technical Notes
|
||||
- Current client has `id: ''` placeholder (TODO in code)
|
||||
- Need Application model in database
|
||||
- App credentials similar to OAuth client credentials
|
||||
- Validate redirect URIs to prevent open redirector attacks
|
||||
- App ID should be included in JWT claims
|
||||
|
||||
## Related TODOs
|
||||
- `ts_idpclient/classes.idpclient.ts:30` - `id: '', // TODO`
|
||||
@@ -0,0 +1,28 @@
|
||||
# Register OAuth Client App
|
||||
|
||||
**ID:** DEV-005
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to register my application as an OAuth client so that users can authorize my app to access their data using standard OAuth 2.0 flows.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Register OAuth 2.0 client application
|
||||
- [ ] Support Authorization Code flow
|
||||
- [ ] Support PKCE for public clients (mobile/SPA)
|
||||
- [ ] Configure allowed scopes per client
|
||||
- [ ] Consent screen customization
|
||||
- [ ] Token endpoint for code exchange
|
||||
- [ ] Refresh token support
|
||||
- [ ] Client credentials flow for server-to-server
|
||||
|
||||
## Technical Notes
|
||||
- OAuth keywords in package.json suggest this is planned
|
||||
- Implement OAuth 2.0 authorization server endpoints
|
||||
- Scopes: openid, profile, email, organizations
|
||||
- Consider OpenID Connect for identity layer
|
||||
- PKCE is required for mobile and SPA security
|
||||
|
||||
## Related TODOs
|
||||
- New feature - OAuth server implementation
|
||||
@@ -0,0 +1,27 @@
|
||||
# Understand API Rate Limits
|
||||
|
||||
**ID:** DEV-006
|
||||
**Priority:** Low
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want to understand and monitor API rate limits so that I can build applications that respect limits and handle throttling gracefully.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Clear documentation of rate limits per endpoint
|
||||
- [ ] Rate limit headers in API responses (X-RateLimit-*)
|
||||
- [ ] Different limits for different API token tiers
|
||||
- [ ] Dashboard showing current usage vs limits
|
||||
- [ ] Alerts when approaching rate limits
|
||||
- [ ] Retry-After header when rate limited
|
||||
- [ ] Ability to request limit increase
|
||||
|
||||
## Technical Notes
|
||||
- Implement rate limiting middleware (consider express-rate-limit)
|
||||
- Store rate limit counters in Redis for distributed systems
|
||||
- Different limits: login attempts, API calls, token operations
|
||||
- Consider sliding window algorithm for smooth limits
|
||||
- 429 Too Many Requests response with helpful error message
|
||||
|
||||
## Related TODOs
|
||||
- New feature - API management
|
||||
@@ -0,0 +1,27 @@
|
||||
# Validate JWTs in My Application
|
||||
|
||||
**ID:** DEV-007
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As a developer, I want clear guidance and tools to validate JWTs issued by the identity provider so that I can securely authenticate users in my backend services.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Public key endpoint for JWT validation (JWKS format)
|
||||
- [ ] Documentation explaining JWT structure and claims
|
||||
- [ ] Example code for validation in multiple languages
|
||||
- [ ] Key rotation with multiple valid keys during transition
|
||||
- [ ] Token introspection endpoint for server-side validation
|
||||
- [ ] Clear error messages for invalid tokens
|
||||
- [ ] Guidance on caching public keys
|
||||
|
||||
## Technical Notes
|
||||
- `getPublicKeyForValidation` endpoint exists
|
||||
- Consider standard JWKS endpoint (/.well-known/jwks.json)
|
||||
- OpenID Connect discovery endpoint would help
|
||||
- JWTs contain: sub, email, roles, orgId, exp, iat
|
||||
- Document all custom claims in JWT
|
||||
|
||||
## Related TODOs
|
||||
- Enhancement to existing JWT infrastructure
|
||||
@@ -0,0 +1,24 @@
|
||||
# Multi-Device Login Sessions
|
||||
|
||||
**ID:** EU-001
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to stay logged in on multiple devices simultaneously so that I can access my account from my phone, tablet, and computer without being logged out elsewhere.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can have active sessions on multiple devices at the same time
|
||||
- [ ] Each device gets its own refresh token
|
||||
- [ ] Logging out on one device does not affect sessions on other devices
|
||||
- [ ] User can see all active sessions in account settings
|
||||
- [ ] User can revoke individual sessions remotely
|
||||
|
||||
## Technical Notes
|
||||
- Currently only one refresh token per login session is supported
|
||||
- Need to refactor `LoginSession` to support multiple refresh tokens
|
||||
- Consider storing device metadata (browser, OS, last active time) with each token
|
||||
- JWT blocklist needs to handle individual token revocation
|
||||
|
||||
## Related TODOs
|
||||
- `ts/reception/classes.jwt.ts:39` - `// TODO: handle multiple refresh tokens`
|
||||
@@ -0,0 +1,26 @@
|
||||
# Complete Password Reset Flow
|
||||
|
||||
**ID:** EU-002
|
||||
**Priority:** Critical
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to reset my password when I forget it so that I can regain access to my account securely.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can request a password reset via email
|
||||
- [ ] Reset email contains a secure, time-limited token link
|
||||
- [ ] Clicking the link opens a form to set a new password
|
||||
- [ ] Password must meet security requirements (length, complexity)
|
||||
- [ ] Old password is invalidated after successful reset
|
||||
- [ ] User receives confirmation email after password change
|
||||
- [ ] All existing sessions are invalidated after password reset
|
||||
|
||||
## Technical Notes
|
||||
- `resetPassword` handler exists but `setNewPassword` is a stub (returns `{ status: 'ok' }` without implementation)
|
||||
- Need to implement actual password update logic
|
||||
- Should use `ReceptionMailer` for email sending
|
||||
- Consider rate limiting reset requests to prevent abuse
|
||||
|
||||
## Related TODOs
|
||||
- `ts/reception/classes.loginsessionmanager.ts:229-238` - `setNewPassword` handler is incomplete
|
||||
@@ -0,0 +1,25 @@
|
||||
# View and Manage Logged-in Devices
|
||||
|
||||
**ID:** EU-003
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to view all devices where I'm logged in and remotely log out of specific devices so that I can maintain control over my account security.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can view a list of all active sessions/devices
|
||||
- [ ] Each device entry shows: device type, browser, location (approximate), last activity
|
||||
- [ ] User can name/label devices for easy identification
|
||||
- [ ] User can log out of any individual device remotely
|
||||
- [ ] User can log out of all devices except the current one
|
||||
- [ ] User receives notification when a new device logs in
|
||||
|
||||
## Technical Notes
|
||||
- Device ID tracking infrastructure exists but is blocked by JWT handling issues
|
||||
- Need to complete `attachDeviceId` handler (currently returns `ok: false`)
|
||||
- Store device fingerprint, user agent, IP-based geolocation
|
||||
- Integrate with multi-refresh-token system (EU-001)
|
||||
|
||||
## Related TODOs
|
||||
- `ts/reception/classes.loginsessionmanager.ts:256` - `// TODO: Blocked by proper JWT handling`
|
||||
@@ -0,0 +1,27 @@
|
||||
# Enable Two-Factor Authentication
|
||||
|
||||
**ID:** EU-004
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to enable two-factor authentication on my account so that my account is protected even if my password is compromised.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can enable 2FA from account settings
|
||||
- [ ] Support for TOTP apps (Google Authenticator, Authy, etc.)
|
||||
- [ ] Backup codes are generated and shown once during setup
|
||||
- [ ] User must verify 2FA code during setup to confirm it works
|
||||
- [ ] Login flow prompts for 2FA code when enabled
|
||||
- [ ] User can disable 2FA (requires current 2FA code)
|
||||
- [ ] Account recovery option if 2FA device is lost
|
||||
|
||||
## Technical Notes
|
||||
- Mobile verification infrastructure exists (SMS OTP in registration)
|
||||
- Can leverage existing `smarttwilio` integration for SMS-based 2FA
|
||||
- TOTP implementation needs `otplib` or similar library
|
||||
- Store encrypted TOTP secret in User model
|
||||
- Consider supporting multiple 2FA methods (TOTP, SMS, security keys)
|
||||
|
||||
## Related TODOs
|
||||
- New feature - no existing TODO
|
||||
@@ -0,0 +1,28 @@
|
||||
# Login with Social Providers
|
||||
|
||||
**ID:** EU-005
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to log in using my existing Google, GitHub, or Microsoft account so that I don't have to remember another password.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can sign in with Google
|
||||
- [ ] User can sign in with GitHub
|
||||
- [ ] User can sign in with Microsoft
|
||||
- [ ] First-time social login creates a new account automatically
|
||||
- [ ] Social login can be linked to existing account
|
||||
- [ ] User can unlink social providers from settings
|
||||
- [ ] Profile data (name, email, avatar) is imported from provider
|
||||
- [ ] User can still set a password for email/password login
|
||||
|
||||
## Technical Notes
|
||||
- Package.json keywords mention OAuth - infrastructure may be partially planned
|
||||
- Implement OAuth 2.0 / OpenID Connect flows
|
||||
- Store provider tokens securely for API access if needed
|
||||
- Handle email conflicts (social email matches existing account)
|
||||
- Consider using passport.js or similar for provider abstraction
|
||||
|
||||
## Related TODOs
|
||||
- New feature - OAuth mentioned in package.json keywords but not implemented
|
||||
@@ -0,0 +1,28 @@
|
||||
# Delete My Account
|
||||
|
||||
**ID:** EU-006
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to permanently delete my account and all associated data so that I can exercise my right to be forgotten (GDPR compliance).
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can request account deletion from settings
|
||||
- [ ] Deletion requires password confirmation or 2FA
|
||||
- [ ] User sees summary of what will be deleted
|
||||
- [ ] Grace period (e.g., 30 days) before permanent deletion
|
||||
- [ ] User receives email confirmation of deletion request
|
||||
- [ ] User can cancel deletion during grace period
|
||||
- [ ] All personal data is removed after grace period
|
||||
- [ ] User is removed from all organizations they belong to
|
||||
|
||||
## Technical Notes
|
||||
- `suspendUser` and `deleteSuspendedUser` endpoints exist in admin context
|
||||
- Need user-facing self-service deletion flow
|
||||
- Consider soft delete with scheduled hard delete
|
||||
- Must handle organization ownership transfer if user owns orgs
|
||||
- Audit log should retain anonymized record for compliance
|
||||
|
||||
## Related TODOs
|
||||
- New feature - builds on existing suspension infrastructure
|
||||
@@ -0,0 +1,26 @@
|
||||
# View Login History
|
||||
|
||||
**ID:** EU-007
|
||||
**Priority:** Low
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to view my login history so that I can detect any unauthorized access to my account.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can view list of recent logins (last 30 days)
|
||||
- [ ] Each entry shows: date/time, IP address, location, device/browser
|
||||
- [ ] Failed login attempts are also shown
|
||||
- [ ] Suspicious logins are highlighted (new location, unusual time)
|
||||
- [ ] User can export login history
|
||||
- [ ] User receives alert for logins from new locations/devices
|
||||
|
||||
## Technical Notes
|
||||
- Login events need to be logged with metadata
|
||||
- Create new LoginHistory collection in MongoDB
|
||||
- IP geolocation service needed (consider MaxMind or ipinfo.io)
|
||||
- Privacy considerations: IP retention policy, GDPR compliance
|
||||
- Could integrate with EU-003 (device management) for unified view
|
||||
|
||||
## Related TODOs
|
||||
- New feature - no existing infrastructure
|
||||
@@ -0,0 +1,28 @@
|
||||
# Upload Profile Avatar
|
||||
|
||||
**ID:** EU-008
|
||||
**Priority:** Low
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an end user, I want to upload a profile picture so that my identity is visually recognizable across applications that use this identity provider.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] User can upload an image from their device
|
||||
- [ ] Supported formats: JPEG, PNG, GIF
|
||||
- [ ] Maximum file size: 5MB
|
||||
- [ ] Image is automatically resized/cropped to standard dimensions
|
||||
- [ ] User can crop/adjust image before saving
|
||||
- [ ] Avatar is served via CDN for fast loading
|
||||
- [ ] Default avatar (initials or Gravatar) when no upload
|
||||
- [ ] Avatar is available to connected applications via API
|
||||
|
||||
## Technical Notes
|
||||
- User model needs avatar URL field
|
||||
- Consider using cloud storage (S3, Cloudflare R2) for images
|
||||
- Implement image processing for resize/crop (sharp library)
|
||||
- Gravatar integration as fallback using email hash
|
||||
- Expose avatar in JWT claims or user info endpoint
|
||||
|
||||
## Related TODOs
|
||||
- New feature - no existing infrastructure
|
||||
@@ -0,0 +1,27 @@
|
||||
# Sync Billing Plans with Users
|
||||
|
||||
**ID:** ORG-001
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want billing plans to automatically sync with user seats so that I'm only charged for active users and can easily manage costs.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Adding a user to org automatically updates billing (for per-seat plans)
|
||||
- [ ] Removing a user adjusts billing accordingly
|
||||
- [ ] Prorated charges/credits for mid-cycle changes
|
||||
- [ ] Organization dashboard shows current seat count vs plan limit
|
||||
- [ ] Warning notification when approaching seat limit
|
||||
- [ ] Automatic upgrade prompt when exceeding limit
|
||||
- [ ] Billing history shows seat changes over time
|
||||
|
||||
## Technical Notes
|
||||
- `BillingPlan.syncForUser()` method exists but is not implemented
|
||||
- Paddle integration exists for payment processing
|
||||
- Need to track user-to-organization seat assignments
|
||||
- Consider grace period for temporary overages
|
||||
- Webhook from Paddle for payment confirmations
|
||||
|
||||
## Related TODOs
|
||||
- `ts/reception/classes.billingplan.ts:16` - `// TODO sync this for user`
|
||||
@@ -0,0 +1,28 @@
|
||||
# Invite and Manage Team Members
|
||||
|
||||
**ID:** ORG-002
|
||||
**Priority:** Critical
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to invite team members to my organization and manage their access so that my team can collaborate securely.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Owner can invite users via email address
|
||||
- [ ] Invited user receives email with invitation link
|
||||
- [ ] Invitation can be accepted by existing users or during registration
|
||||
- [ ] Owner can view pending invitations and resend/cancel them
|
||||
- [ ] Owner can see all current members with their roles
|
||||
- [ ] Owner can remove members from organization
|
||||
- [ ] Owner can transfer ownership to another member
|
||||
- [ ] Bulk invite via CSV upload
|
||||
|
||||
## Technical Notes
|
||||
- Organization and User models exist with association
|
||||
- Need new Invitation model with token and expiry
|
||||
- Use `ReceptionMailer` for invitation emails
|
||||
- RoleManager can be leveraged for role assignment
|
||||
- Consider invitation expiry (7 days default)
|
||||
|
||||
## Related TODOs
|
||||
- New feature - core organizational functionality
|
||||
@@ -0,0 +1,28 @@
|
||||
# Assign Roles to Members
|
||||
|
||||
**ID:** ORG-003
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to assign different roles to team members so that I can control what each person can access and do within the organization.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Owner can create custom roles for the organization
|
||||
- [ ] Default roles: Owner, Admin, Member, Viewer
|
||||
- [ ] Each role has configurable permissions
|
||||
- [ ] Owner can assign/change roles for any member
|
||||
- [ ] Role changes take effect immediately
|
||||
- [ ] Members can view their own role and permissions
|
||||
- [ ] Audit log for role changes
|
||||
- [ ] At least one Owner must exist at all times
|
||||
|
||||
## Technical Notes
|
||||
- RoleManager exists with basic role infrastructure
|
||||
- `getRolesAndOrganizationsForUserId` endpoint available
|
||||
- Need to expand Role model with permissions array
|
||||
- Consider permission inheritance (Admin inherits Member permissions)
|
||||
- JWT claims should include role for authorization
|
||||
|
||||
## Related TODOs
|
||||
- Partial implementation exists in RoleManager
|
||||
@@ -0,0 +1,27 @@
|
||||
# Customize Organization Branding
|
||||
|
||||
**ID:** ORG-004
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to customize the branding of my organization's login and account pages so that my team sees our company identity when authenticating.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Upload organization logo
|
||||
- [ ] Set primary and secondary brand colors
|
||||
- [ ] Custom login page welcome message
|
||||
- [ ] Organization name displayed on login/register
|
||||
- [ ] Preview branding changes before saving
|
||||
- [ ] Reset to default branding option
|
||||
- [ ] Branding applies to email templates (org-specific emails)
|
||||
|
||||
## Technical Notes
|
||||
- Organization model needs branding fields (logo URL, colors, message)
|
||||
- Frontend components need to accept branding props
|
||||
- Email templates should support organization branding
|
||||
- Consider white-label subdomain support (org.idp.global)
|
||||
- Image storage similar to user avatars (EU-008)
|
||||
|
||||
## Related TODOs
|
||||
- New feature - no existing infrastructure
|
||||
@@ -0,0 +1,27 @@
|
||||
# View Organization Usage Analytics
|
||||
|
||||
**ID:** ORG-005
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to view analytics about how my organization uses the identity platform so that I can understand adoption and identify potential issues.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Dashboard showing key metrics (active users, logins, registrations)
|
||||
- [ ] Time-series charts for login activity
|
||||
- [ ] Most active users ranking
|
||||
- [ ] Failed login attempts summary
|
||||
- [ ] Authentication method breakdown (password, email link, 2FA)
|
||||
- [ ] Date range selector for historical data
|
||||
- [ ] Export analytics data (CSV, PDF)
|
||||
|
||||
## Technical Notes
|
||||
- Need to aggregate login events per organization
|
||||
- Consider time-series database or aggregation pipeline in MongoDB
|
||||
- Privacy: show aggregates, not individual user activity details
|
||||
- Cache analytics for performance
|
||||
- Real-time updates via WebSocket for dashboard
|
||||
|
||||
## Related TODOs
|
||||
- New feature - requires event logging infrastructure
|
||||
@@ -0,0 +1,28 @@
|
||||
# Configure SSO for Organization
|
||||
|
||||
**ID:** ORG-006
|
||||
**Priority:** High
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to configure Single Sign-On with my company's identity provider so that employees can use their corporate credentials.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Support SAML 2.0 SSO configuration
|
||||
- [ ] Support OIDC/OAuth SSO configuration
|
||||
- [ ] Test connection before enabling
|
||||
- [ ] Auto-provision users on first SSO login (JIT provisioning)
|
||||
- [ ] Map SSO attributes to user profile fields
|
||||
- [ ] Option to require SSO for all org members
|
||||
- [ ] Bypass SSO for emergency admin access
|
||||
- [ ] Support multiple SSO providers per organization
|
||||
|
||||
## Technical Notes
|
||||
- Implement SAML assertion consumer service
|
||||
- Store SSO configuration securely (encrypted secrets)
|
||||
- Certificate management for SAML
|
||||
- Consider using passport-saml and passport-openidconnect
|
||||
- Metadata endpoint for easy IdP configuration
|
||||
|
||||
## Related TODOs
|
||||
- New feature - enterprise SSO capability
|
||||
@@ -0,0 +1,28 @@
|
||||
# View Organization Audit Logs
|
||||
|
||||
**ID:** ORG-007
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to view audit logs for my organization so that I can track security-relevant events and meet compliance requirements.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Log all security-relevant events (logins, role changes, member changes)
|
||||
- [ ] Searchable audit log interface
|
||||
- [ ] Filter by event type, user, date range
|
||||
- [ ] Each entry shows: timestamp, actor, action, target, IP address
|
||||
- [ ] Immutable logs (cannot be deleted or modified)
|
||||
- [ ] Export logs for compliance (CSV, JSON)
|
||||
- [ ] Retention policy configuration (90 days default)
|
||||
- [ ] Real-time event streaming option
|
||||
|
||||
## Technical Notes
|
||||
- Create AuditLog collection with write-only access pattern
|
||||
- Index for efficient querying
|
||||
- Consider separate database/collection for audit data
|
||||
- Comply with SOC 2 / ISO 27001 logging requirements
|
||||
- Webhook option for SIEM integration
|
||||
|
||||
## Related TODOs
|
||||
- New feature - compliance and security requirement
|
||||
@@ -0,0 +1,28 @@
|
||||
# Manage Subscription and Billing
|
||||
|
||||
**ID:** ORG-008
|
||||
**Priority:** Medium
|
||||
**Status:** Planned
|
||||
|
||||
## User Story
|
||||
As an organization owner, I want to manage my subscription plan and billing details so that I can upgrade, downgrade, or update payment methods as needed.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] View current subscription plan and features
|
||||
- [ ] Compare available plans with feature matrix
|
||||
- [ ] Upgrade to higher plan with immediate effect
|
||||
- [ ] Downgrade with effect at end of billing period
|
||||
- [ ] Update payment method (credit card via Paddle)
|
||||
- [ ] View billing history and download invoices
|
||||
- [ ] Cancel subscription with confirmation
|
||||
- [ ] Apply coupon/discount codes
|
||||
|
||||
## Technical Notes
|
||||
- Paddle integration exists (`paddlesetup` view, `BillingPlanManager`)
|
||||
- Enhance existing subscription view with more functionality
|
||||
- Paddle handles PCI compliance for payment data
|
||||
- Webhook handlers for subscription status changes
|
||||
- VAT handling for EU customers (Paddle manages this)
|
||||
|
||||
## Related TODOs
|
||||
- Enhancement to existing Paddle integration
|
||||
@@ -9,9 +9,10 @@ import {
|
||||
cssManager,
|
||||
unsafeCSS,
|
||||
css,
|
||||
resolveExec,
|
||||
type TemplateResult,
|
||||
directives
|
||||
} from '@design.estate/dees-element';
|
||||
|
||||
import type { IdpViewcontainer } from '../views/viewcontainer.js';
|
||||
import { IdpState } from '../states/idp.state.js';
|
||||
|
||||
@@ -58,7 +59,7 @@ export class IdpWelcome extends DeesElement {
|
||||
<style></style>
|
||||
<idp-centercontainer>
|
||||
<div class="maincontainer">
|
||||
${resolveExec(async () => {
|
||||
${directives.resolveExec(async () => {
|
||||
const idpState = await IdpState.getSingletonInstance();
|
||||
await idpState.idpClient.determineLoginStatus();
|
||||
const data = await idpState.idpClient.whoIs().catch();
|
||||
|
||||
+1
-3
@@ -1,8 +1,6 @@
|
||||
{
|
||||
"compilerOptions": {
|
||||
"experimentalDecorators": true,
|
||||
"useDefineForClassFields": false,
|
||||
"target": "ES2022",
|
||||
"target": "ESNext",
|
||||
"module": "NodeNext",
|
||||
"moduleResolution": "NodeNext",
|
||||
"esModuleInterop": true,
|
||||
|
||||
Reference in New Issue
Block a user