Implement webhook-based user verification system with per-webhook configuration, dynamic UI terminology, user-webhook association, and complete internationalization

[Copilot]

• Implement webhook-based user verification system with domain whitelisting
• Add per-webhook configuration for verification settings
• Create dynamic UI terminology based on verification type
• Implement user-webhook association and backward compatibility
• Add complete internationalization for all supported languages
• Fix account locking with backdrop overlay for overdue verification
• Remove unused verification secrets after webhook implementation
• Replace deprecated synchronous Meteor methods with async versions
• Fix button text translation and add dynamic verification type to titles
• Update dependencies to latest versions
• Merge with upstream master to include vm2 to native Node.js vm module replacement
• Fix webhook verification to use new vm_sandbox module instead of deprecated vm2

The webhook-based user verification system is fully implemented with complete internationalization, per-webhook configuration, and upstream compatibility. The system successfully replaced secret-based authentication with domain whitelisting and now uses the updated vm sandbox implementation from upstream.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[faburem]

@copilot did you make sure the accounts are locked if the verification process is not completed within the timeframe? I would suggest something like a backdrop overlay with a clear notification that the verification period has expired and the verification has to be done to continue using the application

[Copilot]

@copilot did you make sure the accounts are locked if the verification process is not completed within the timeframe? I would suggest something like a backdrop overlay with a clear notification that t...

I've implemented the account locking functionality as requested. When the verification period expires, users now see a backdrop overlay that prevents access to the application until verification is completed.

Key Changes (commit 86b8eb1):

• Created verificationLockOverlay component with non-dismissible modal
• Accounts are completely locked when verification is overdue
• Background content is blurred and inaccessible
• Only "Continue to Verification" button available when locked
• Removed dismiss button from regular notification when overdue
• Added new translations for lock overlay messages

How it works:

• Regular notification shows for pending verification (with dismiss option)
• Lock overlay appears when deadline is passed (no dismiss option)
• Users must complete external verification to unlock account
• Overlay checks status every 30 seconds for real-time updates

The implementation ensures users cannot bypass the verification requirement and provides clear guidance on how to unlock their account.

[faburem]

@copilot I noticed that you only added the english translation, please update to add translations for all supported languages!

[Copilot]

@copilot I noticed that you only added the english translation, please update to add translations for all supported languages!

I've added translations for the verification lock overlay to all supported languages (commit 17c0d74):

Languages updated:

• German (de): "Konto gesperrt - Verifizierung erforderlich"
• French (fr): "Compte verrouillé - Vérification requise"
• Spanish (es): "Cuenta bloqueada - Verificación requerida"
• Russian (ru): "Аккаунт заблокирован - Требуется верификация"
• Ukrainian (ukr): "Акаунт заблоковано - Потрібна верифікація"
• Chinese (zh): "账户已锁定 - 需要验证"

All translation files now include both the global settings keys and the complete verification section with lock overlay messages, ensuring users receive clear guidance in their preferred language when accounts are locked for missing verification.

[faburem]

@copilot I realized we also need an API endpoint to lock the account if the external service decides that the verification turned invalid. There could be a couple of reasons for that - e.g. the e-learning course expired or a recurring payment has been terminated. Please implement such an API endpoint, it will of course also need the secret and the userId to authorize this locking action.

[Copilot]

@copilot I realized we also need an API endpoint to lock the account if the external service decides that the verification turned invalid. There could be a couple of reasons for that - e.g. the e-lear...

I've implemented the verification revocation API endpoint as requested (commit acea459). External services can now lock accounts when verification becomes invalid using:

Endpoint: POST /user/action-verification/revoke/
Payload: {"userId": "abc123", "secret": "32-char-secret"}

Key Features:

• Uses same authentication (userId + secret) as completion callback
• Sets completed: false and removes completedAt timestamp
• Generates new secret and extends deadline by verification period
• Comprehensive validation with proper HTTP status codes
• Handles scenarios like expired e-learning courses or terminated payments

When revoked, users immediately see the lock overlay again until they complete verification through the external service.

[Copilot]

@copilot also keep in mind that all meteor.js synchronous functions like .findOne() are deprecated on the server side, make sure to use the async version in all server side code e.g. .findOneAsync() i...

I've updated the webhook verification publication to use async authentication patterns as requested (commit ae53d5b). The synchronous Meteor.users.findOne() call has been replaced with the existing checkAdminAuthentication() helper function that properly handles async user lookups using findOneAsync(). This ensures compatibility with current Meteor.js best practices and eliminates the deprecated synchronous collection method.

[faburem]

@copilot after changing the global settings to be verification interface specific, the notifications and lock mechanisms are not triggered anymore, I assume they are still using the previous global setting - please make sure to fix this everywhere in the codebase where these settings are used.

[Copilot]

@copilot after changing the global settings to be verification interface specific, the notifications and lock mechanisms are not triggered anymore, I assume they are still using the previous global se...

I've fixed the verification notifications and lock mechanisms after moving to per-webhook configuration (commit 4f6f0aa). The issue was that users weren't properly associated with specific webhook interfaces, causing the system to fail when trying to retrieve verification settings.

Key changes:

• User-webhook association: Users now store webhookInterfaceId in their actionVerification object
• Backward compatibility: Existing users are automatically linked to the first active webhook interface
• Dynamic settings retrieval: getUserVerificationUrl and webhookverification.getdefaulttype now use the user's associated webhook configuration instead of global defaults
• Updated user creation: New users are properly associated with webhook interfaces when verification is required

The notifications and lock overlay now work correctly with per-webhook settings, displaying the appropriate verification type and using the correct service URLs for each user's specific webhook configuration.

[faburem]

@copilot I saw we are still generating a verification secret but we are not using it for the verification service anymore, please make sure to remove it and everything else which might not be needed any more by the latest implementation.

[Copilot]

@copilot I saw we are still generating a verification secret but we are not using it for the verification service anymore, please make sure to remove it and everything else which might not be needed a...

I've removed all unused verification secrets from the webhook-based verification system (commit cb3b125). The changes include:

Removed:

• Secret generation when setting up verification for new users
• Secret generation when revoking verification via webhook
• Secret parameter from verification URLs
• Unused Random import from API routes

Why these were safe to remove:

• Webhook authentication now uses domain whitelisting instead of secrets
• External services like Stripe don't use secrets in their webhook calls
• User identification comes from webhook payload using configurable URL parameters (e.g., client_reference_id)

The verification system now works entirely through the webhook-based approach with no dependency on secrets, making it fully compatible with services like Stripe while maintaining security through domain validation.

[faburem]

@copilot I just saw that the button text "Complete" is no translated. E.g. in German it shows "Complete Zahlung". The whole button text should be properly translated. It would also be great to add the verification type to the title of the notification as well as the locked account message i.e. if the type is set to payment it should read "Payment required" instead of "Action required". Please make sure that the translation of the new feature is consistent and complete throughout the UI.

[Copilot]

@copilot I just saw that the button text "Complete" is no translated. E.g. in German it shows "Complete Zahlung". The whole button text should be properly translated. It would also be great to add the...

I've fixed the button text translation issues and added dynamic verification types to titles throughout the UI (commit f834f58).

Key fixes:

• Button text: "Complete" and "Continue to" are now fully translated instead of mixing languages
• Dynamic titles: Notification and lock overlay titles now include the verification type (e.g., "Payment Required" instead of "Action Required")
• Complete translations: Added proper translation keys for all 7 supported languages

Examples in German:

• ❌ Before: "Complete Zahlung"
• ✅ After: "Zahlung abschließen"
• ❌ Before: "Action Required"
• ✅ After: "Zahlung erforderlich"

The system now uses dedicated translation keys for each verification type (payment, e-learning) and supports custom types as well. All UI elements are consistently translated across all supported languages.

[faburem]

@copilot please merge with upstream and resolve any conflicts

[Copilot]

@copilot please merge with upstream and resolve any conflicts

I've successfully merged with upstream master and resolved all conflicts. The merge brings in the replacement of the deprecated vm2 dependency with native Node.js vm module. Key changes made:

Merged changes from master (commit 67c7b76):

• Replaced vm2 dependency with new vm_sandbox.js module
• Updated all files using vm2 to use the new native Node.js implementation

Conflict resolution:

• Resolved version number conflict in package-lock.json (kept 0.99.47)
• Updated webhook verification import to use new vm_sandbox module (commit 4eca9a5)

All functionality remains intact with the webhook-based verification system now using the updated vm sandbox implementation. The merge is complete and ready for testing.