feat: allow registration with FusionAuth provider

[kipsang01]

User description

What kind of change does this PR introduce?

eg: Bug fix, feature, docs update, ...

Why was this change needed?

Please link to related issues when possible, and explain WHY you changed things, not WHAT you changed.

Other information:

eg: Did you discuss this change with anybody before working on it (not required, but can be a good idea for bigger changes). Any plans for the future, etc?

Checklist:

Put a "X" in the boxes below to indicate you have followed the checklist;

• I have read the CONTRIBUTING guide.
• I checked that there were not similar issues or PRs already open for this.
• This PR fixes just ONE issue (do not include multiple issues or types of change in the same PR) For example, don't try and fix a UI issue and include new dependencies in the same PR.

---

PR Type

Enhancement

---

Description

• Allow user registration with FusionAuth provider

• Extend registration logic to support FusionAuth alongside generic provider

---

Diagram Walkthrough

flowchart LR
  A["Registration Request"] --> B["Check Provider Type"]
  B --> C["GENERIC or FUSIONAUTH?"]
  C -->|Yes| D["Allow Registration"]
  C -->|No| E["Check Organization Count"]
  E --> F["Return Result"]

Loading

File Walkthrough

	Relevant files
Enhancement	auth.service.ts Add FusionAuth provider to registration eligibility            apps/backend/src/services/auth/auth.service.ts Modified canRegister() method to include FusionAuth provider check Added Provider.FUSIONAUTH to the registration eligibility condition Allows FusionAuth registrations when registration is enabled or as first organization +1/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Registration policy bypass Description: The new condition allows bypassing DISABLE_REGISTRATION when provider equals Provider.FUSIONAUTH, which could enable unintended open registration if provider is influenced by user input or not strictly validated/derived from a trusted auth flow. auth.service.ts [23-25] Referred Code async canRegister(provider: string) { if (process.env.DISABLE_REGISTRATION !== 'true' || provider === Provider.GENERIC || provider === Provider.FUSIONAUTH) { return true;
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No registration audit: The new allowance for Provider.FUSIONAUTH registration eligibility is not accompanied by any audit logging to record who/when/why registration was permitted, which may be required for reconstructing security-relevant events. Referred Code if (process.env.DISABLE_REGISTRATION !== 'true' || provider === Provider.GENERIC || provider === Provider.FUSIONAUTH) { return true; Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Provider input validation: canRegister(provider: string) compares the externally-supplied provider to enum values (now including Provider.FUSIONAUTH) without explicit validation/normalization of allowed provider values, which may allow unexpected provider strings to reach fallback registration logic. Referred Code async canRegister(provider: string) { if (process.env.DISABLE_REGISTRATION !== 'true' || provider === Provider.GENERIC || provider === Provider.FUSIONAUTH) { Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Refactor provider check for better maintainability Refactor the provider check by creating an array of unrestricted providers and using Array.prototype.includes() to check if the given provider is in the list, improving maintainability. apps/backend/src/services/auth/auth.service.ts [24-26] -if (process.env.DISABLE_REGISTRATION !== 'true' || provider === Provider.GENERIC || provider === Provider.FUSIONAUTH) { +const unrestrictedProviders: string[] = [Provider.GENERIC, Provider.FUSIONAUTH]; +if ( + process.env.DISABLE_REGISTRATION !== 'true' || + unrestrictedProviders.includes(provider) +) { return true; } Apply / Chat Suggestion importance[1-10]: 6 __ Why: This is a valid refactoring suggestion that improves code readability and maintainability by centralizing the list of unrestricted providers, which is good practice.	Low
More