Feature/register Support new account creation/registration #579

TigerInYourDream · 2025-09-05T11:11:38Z

Summary

Implemented a complete user registration flow for Matrix accounts with support for both password-based and SSO registration methods.

Key Features

Full registration screen UI with modern design
Dual registration methods:
- Password-based registration for custom homeservers
- SSO registration via Google OAuth for matrix.org
Smart homeserver selection with automatic mode switching
Comprehensive form validation:
- Username requirement checking
- Password minimum length (8 characters)
- Password confirmation matching
- Custom homeserver URL validation
Registration status modal with real-time feedback
SSO state management synchronized with login screen
Clean error handling with user-friendly notifications

Technical Implementation

Follows Element's approach: SSO flow shared between login and registration
Matrix server automatically handles account creation vs login based on OAuth identity
Integrated with existing authentication infrastructure
Consistent UX patterns with login screen
Simplified UIA handling (supports m.login.dummy flow)

UI/UX Improvements

Clear visual feedback during registration process
Disabled button states to prevent duplicate submissions
Informative status messages during SSO flow
Responsive modal dialogs for registration status
Consistent styling with existing Robrix design language

## Summary Implemented a complete user registration flow for Matrix accounts with support for both password-based and SSO registration methods. ## Key Features - Full registration screen UI with modern design - Dual registration methods: - Password-based registration for custom homeservers - SSO registration via Google OAuth for matrix.org - Smart homeserver selection with automatic mode switching - Comprehensive form validation: - Username requirement checking - Password minimum length (8 characters) - Password confirmation matching - Custom homeserver URL validation - Registration status modal with real-time feedback - SSO state management synchronized with login screen - Clean error handling with user-friendly notifications ## Technical Implementation - Follows Element's approach: SSO flow shared between login and registration - Matrix server automatically handles account creation vs login based on OAuth identity - Integrated with existing authentication infrastructure - Consistent UX patterns with login screen - Simplified UIA handling (supports m.login.dummy flow) ## UI/UX Improvements - Clear visual feedback during registration process - Disabled button states to prevent duplicate submissions - Informative status messages during SSO flow - Responsive modal dialogs for registration status - Consistent styling with existing Robrix design language ## Testing Checklist - [x] Password registration with custom homeserver - [x] SSO registration with matrix.org - [x] Form validation (empty fields, password strength, confirmation) - [x] Modal display and dismissal - [x] Error handling and user notifications - [x] Button state management during async operations

- Use if-let instead of match for single pattern - Replace useless format! with to_string()

…ling Major improvements to registration screen: 1. SSO Registration Support: - Added source-aware SSO handling with is_registration flag - Register and login screens now have independent action flows - Proper modal display during SSO authentication - Automatic modal updates with status messages 2. Modal Handling Fixes: - Fixed non-clickable Cancel/Abort buttons in registration modals - Implemented proper was_internal pattern for modal close events - Added button mask state (gray out) during processing - Correct modal text for password vs SSO registration 3. UI/UX Consistency: - Unified modal styles between login and register screens (285px width) - Consistent padding, spacing, colors (#CCC background) - Matching title sections and button styles - Unified outer screen styles (#FFF background) 4. Code Quality: - Simplified RegisterAction enum (removed redundant variants) - Complete decoupling between login and register SSO flows - Clear documentation of SSO action handling architecture - Fixed all layout and z-index issues Technical details: - SpawnSSOServer now includes is_registration flag - sliding_sync.rs sends appropriate actions based on source - Each screen only processes its own action types - Modal shows immediately on SSO button click for better UX

- Close registration modal after successful password registration Previously the modal remained invisible but active, blocking UI interactions - Prevent false offline notifications for normal sync states Only Error, Terminated, and Offline states now trigger connection error popups Idle and Running states are normal operational states This fixes issues where users would see incorrect error messages after registration when the sync service is actually working properly.

Signed-off-by: Alvin <zyzzz0928@gmail.com>

Resolved conflicts in: - src/app.rs: Integrated register functionality with updated imports and view logic - src/home/main_desktop_ui.rs: Updated to use ids! macro - src/home/rooms_list_header.rs: Preserved enhanced offline state handling with ids! macro - src/sliding_sync.rs: Merged register support with new main features (link preview, tombstone)

Copilot

Pull Request Overview

This PR implements a comprehensive user registration feature for Matrix accounts, supporting both password-based registration for custom homeservers and SSO registration (via Google OAuth) for matrix.org. The implementation follows Element's approach where the SSO flow is shared between login and registration, with the Matrix server automatically determining whether to create a new account or log in an existing user.

Key Changes

New registration screen with dual registration modes (password/SSO) and homeserver selection
Registration logic with UIA (User-Interactive Authentication) handling for m.login.dummy and m.login.registration_token flows
SSO flow enhancement to support both login and registration contexts with dedicated action types

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 16 comments.

Show a summary per file

File	Description
src/sliding_sync.rs	Adds `register_user()` function for password registration with UIA support, new `MatrixRequest::Register` variant, and enhances `spawn_sso_server()` to handle both login and registration
src/register/register_screen.rs	Complete registration UI with homeserver selection, form validation, password/SSO modes, and state management
src/register/register_status_modal.rs	Modal dialog for displaying registration progress with cancel functionality
src/register/mod.rs	Module definition for registration components
src/app.rs	Navigation handling between login/register screens and registration success flow
src/login/login_screen.rs	Replaces external signup URL with navigation to new register screen
src/lib.rs	Adds register module declaration
src/home/main_desktop_ui.rs	Adds state reset to prevent dock restoration issue
src/home/rooms_list_header.rs	Refines offline notification logic to avoid spurious error popups

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-11-12T02:47:38Z

src/sliding_sync.rs

+                    // Server requires registration token authentication
+                    // Registration tokens are pre-shared tokens that must be obtained out-of-band
+                    // (e.g., from server administrator via email, chat, or other means)
+                    // Use the user-provided registration token if available


Misleading comment: The comment states "Registration tokens are pre-shared tokens that must be obtained out-of-band (e.g., from server administrator via email, chat, or other means)" but the PR description explicitly states "Registration token support has been intentionally omitted for simplicity."

This comment suggests the feature is implemented when it's actually intentionally excluded. Consider either removing this misleading comment or clarifying that this code path is present but the UI doesn't expose it to users.

Suggested change

// Use the user-provided registration token if available

// NOTE: Registration token support is not exposed in the UI; this code path exists for completeness,

// but users cannot currently provide a registration token via the UI.

Copilot · 2025-11-12T02:47:38Z

src/sliding_sync.rs

+                    match client.matrix_auth().register(req).await {
+                        Ok(_) => {
+                            log!("Registration succeeded with registration token");
+                        }


Error message inspection: The error is being inspected via string matching with e.to_string().contains("Invalid registration token"). This is fragile as error messages can change between SDK versions.

Consider using proper error type matching if the SDK provides specific error types, or at least document that this is a best-effort approach that may need updates.

Suggested change

}

}

// NOTE: This string match is a best-effort approach.

// If the SDK exposes a specific error type/variant for invalid registration token,

// prefer matching on that instead of the error message string.

// This may need to be updated if the SDK changes error messages.

Copilot · 2025-11-12T02:47:39Z

src/register/register_screen.rs

+                    // Update SSO status in modal (only if our modal is already open)
+                    if self.sso_pending {
+                        let status_label = self.view.label(id!(status_modal_inner.status));
+                        status_label.set_text(cx, status);
+                        let cancel_button = self.view.button(id!(status_modal_inner.cancel_button));
+                        cancel_button.set_text(cx, "Cancel");
+                        self.redraw(cx);
+                    }


[nitpick] Potential logic issue with SSO status updates: The code checks if self.sso_pending at line 696 before updating the status label. However, if SsoRegistrationStatus actions arrive before SsoRegistrationPending(true) is processed (due to async timing), the status updates could be lost.

Consider removing the sso_pending check or ensuring the modal is opened before any status updates can arrive.

Suggested change

// Update SSO status in modal (only if our modal is already open)

if self.sso_pending {

let status_label = self.view.label(id!(status_modal_inner.status));

status_label.set_text(cx, status);

let cancel_button = self.view.button(id!(status_modal_inner.cancel_button));

cancel_button.set_text(cx, "Cancel");

self.redraw(cx);

}

// Update SSO status in modal (update regardless of sso_pending to avoid race condition)

let status_label = self.view.label(id!(status_modal_inner.status));

status_label.set_text(cx, status);

let cancel_button = self.view.button(id!(status_modal_inner.cancel_button));

cancel_button.set_text(cx, "Cancel");

self.redraw(cx);

Copilot · 2025-11-12T02:47:39Z

src/register/register_screen.rs

+                // Basic URL validation - ensure it starts with http:// or https://
+                let trimmed = text_event.trim();
+                let is_valid_url = trimmed.starts_with("http://") || trimmed.starts_with("https://") 
+                    || (!trimmed.contains("://") && !trimmed.is_empty()); // Allow domain-only input
+
+                if is_valid_url {
+                    self.selected_homeserver = text_event.clone();
+                    self.view.label(id!(selected_homeserver)).set_text(cx, &text_event);
+                    self.update_registration_mode(cx);
+                }


Weak URL validation: The custom homeserver URL validation at lines 571-572 is insufficient for security. It only checks if the input starts with http:// or https://, or allows domain-only input. This doesn't validate:

Proper URL format

Prevention of SSRF attacks via malicious URLs

Invalid characters or injection attempts

Consider using a proper URL parsing library (like the url crate already imported) to validate the homeserver URL before using it.

Copilot · 2025-11-12T02:47:39Z

src/register/register_status_modal.rs

+            // Note: This doesn't actually cancel the registration request (still running in background)
+            cx.action(RegisterStatusModalAction::Close {
+                was_internal: abort_clicked 
+            });
+        }


[nitpick] Misleading cancel button behavior: The comment on line 115 states "This doesn't actually cancel the registration request (still running in background)" but the button is labeled "Cancel" (line 79). This could confuse users who expect canceling to actually stop the registration process.

Consider either:

Renaming the button to "Dismiss" or "Hide" to better reflect its actual behavior

Implementing actual cancellation if possible

Adding UI text warning users that the request will continue in the background

Copilot · 2025-11-12T02:47:41Z

src/register/register_screen.rs

+                        let register_button = self.view.button(id!(register_button));
+                        register_button.set_enabled(cx, true);
+                        register_button.reset_hover(cx);


[nitpick] Redundant state reset: At line 726, the register button is being reset even though the same button was already reset by reset_modal_state() at line 664 (when not in SSO mode). This creates duplicate button reset logic. Consider consolidating the button reset logic to avoid redundancy.

Suggested change

let register_button = self.view.button(id!(register_button));

register_button.set_enabled(cx, true);

register_button.reset_hover(cx);

Copilot · 2025-11-12T02:47:41Z

src/register/register_screen.rs

+            // Check password strength - minimum 8 characters
+            if password.len() < 8 {
+                self.show_warning("Password must be at least 8 characters");
+                return;
+            }


[nitpick] Password strength validation is too weak: The current validation only checks for a minimum length of 8 characters (line 608). This doesn't enforce any password complexity requirements such as:

Mix of uppercase/lowercase letters

Numbers

Special characters

Common password checks

While Matrix servers may have their own password policies, client-side validation should provide better user guidance. Consider adding at least basic complexity checks or displaying password strength feedback.

Suggested change

// Check password strength - minimum 8 characters

if password.len() < 8 {

self.show_warning("Password must be at least 8 characters");

return;

}

// Check password strength - minimum 8 characters and complexity

if password.len() < 8 {

self.show_warning("Password must be at least 8 characters");

return;

}

if !password.chars().any(|c| c.is_ascii_lowercase()) {

self.show_warning("Password must contain at least one lowercase letter");

return;

}

if !password.chars().any(|c| c.is_ascii_uppercase()) {

self.show_warning("Password must contain at least one uppercase letter");

return;

}

if !password.chars().any(|c| c.is_ascii_digit()) {

self.show_warning("Password must contain at least one digit");

return;

}

if !password.chars().any(|c| !c.is_ascii_alphanumeric()) {

self.show_warning("Password must contain at least one special character");

return;

}

Copilot · 2025-11-12T02:47:41Z

src/register/register_screen.rs

+            if let Some(reg_action) = action.downcast_ref::<RegisterAction>() {
+                match reg_action {
+                    RegisterAction::RegistrationSuccess => {
+                        // Close modal and let app.rs handle screen transition
+                        self.view.modal(id!(status_modal)).close(cx);
+                        if self.sso_pending {
+                            self.sso_pending = false;
+                            self.update_button_mask(&sso_button, cx, 0.0);
+                        }
+                        self.redraw(cx);
+                    }
+                    RegisterAction::RegistrationFailure(error) => {
+                        // Show error and reset buttons
+                        if self.sso_pending {
+                            self.show_warning(error);
+                            self.sso_pending = false;
+                            self.update_button_mask(&sso_button, cx, 0.0);
+                        }
+                        self.view.modal(id!(status_modal)).close(cx);
+                        let register_button = self.view.button(id!(register_button));
+                        register_button.set_enabled(cx, true);
+                        register_button.reset_hover(cx);
+                        self.redraw(cx);
+                    }
+                    _ => {}
+                }
+            }


Potential state inconsistency: When handling RegistrationSuccess, the code closes the modal and resets button state (lines 709-716), but then later handles the same action again (lines 707-733). This creates duplicate handling of the same action which could lead to the code running twice.

The code structure has overlapping action handlers:

Lines 671-680: Handles LoginAction::LoginSuccess when sso_pending is true

Lines 707-733: Handles RegisterAction cases including RegistrationSuccess

This nested handling could cause issues. Consider restructuring to avoid processing the same action multiple times.

Copilot · 2025-11-12T02:47:41Z

src/app.rs

        if let Some(closure) = close_room_closure_opt {
            closure(cx);
        }
+>>>>>>> origin/main


Merge conflict marker detected. This line should be removed before merging.

Suggested change

>>>>>>> origin/main

Copilot · 2025-11-12T02:47:42Z

src/sliding_sync.rs

+        // Don't save the session here - it will be saved when we convert to LoginBySSOSuccess
+        // This avoids duplicate session persistence


[nitpick] Inconsistent comment: The comment on lines 337-338 states "Don't save the session here - it will be saved when we convert to LoginBySSOSuccess". However, this comment is placed in the password-based registration flow, not the SSO flow.

The password registration returns a client/session that gets passed to LoginBySSOSuccess on line 709, so the comment makes sense in context but could be clearer. Consider moving or clarifying this comment to explain that session persistence happens in the login flow that follows.

Suggested change

// Don't save the session here - it will be saved when we convert to LoginBySSOSuccess

// This avoids duplicate session persistence

// Don't save the session here—session persistence is handled in the login flow that follows

// (e.g., when passing to LoginBySSOSuccess). This avoids duplicate session persistence.

This reverts commit a169504, reversing changes made to 2f747bc.

Signed-off-by: Alvin <zyzzz0928@gmail.com>

TigerInYourDream · 2025-12-05T05:21:24Z

State Transition: Registration → Login

Background

In the Matrix SDK, successful registration also means successful login. This is documented in https://docs.rs/matrix-sdk/0.16.0/matrix_sdk/authentication/matrix/struct.MatrixAuth.html#method.register and verified by
Element's behavior—after registration, users go directly to the chat interface.

The Challenge

Robrix uses different action types for registration (RegisterAction) and login (LoginAction). After successful registration, we need to initialize all global state (CLIENT, SLIDING_SYNC, room lists, etc.) which is already
implemented in the login flow.

Solution

We reuse LoginBySSOSuccess to handle post-registration initialization:

// After successful registration, trigger the login success flow
Cx::post_action(LoginAction::LoginBySSOSuccess(client));

Why LoginBySSOSuccess instead of LoginByPasswordResult?

Aspect	LoginByPasswordResult	LoginBySSOSuccess
Makes network request	Yes (calls login())	No
Expects authenticated client	No	Yes
Use case	Username/password auth	Pre-authenticated client

Registration already authenticates us—we have a valid client and session. LoginBySSOSuccess simply:

Saves the session locally
Initializes global state (CLIENT, SLIDING_SYNC, etc.)
Navigates to the main app

The name LoginBySSOSuccess is somewhat misleading—it's effectively a "UseAuthenticatedClient" action that works for any pre-authenticated client (SSO, registration, restored session, etc.).

okapii and others added 7 commits February 6, 2024 14:54

UI Design

7f93991

Icon folder cleanup

4e3e845

Icons: more cleanups

ef47d65

Initial work new UI design

43cf602

More design rework and DSL restructuring

7ac5ac8

Merge branch 'main' into feature/register-new

f212565

TigerInYourDream changed the title ~~Add comprehensive user registration screen with SSO support~~ Add user registration screen with SSO support Sep 5, 2025

TigerInYourDream changed the title ~~Add user registration screen with SSO support~~ Feature/register Support new account creation/registration Sep 5, 2025

fix: Address clippy warnings

0ef2b32

- Use if-let instead of match for single pattern - Replace useless format! with to_string()

TigerInYourDream force-pushed the feature/register-new branch 2 times, most recently from 3a8c22c to 4ced188 Compare September 8, 2025 09:05

TigerInYourDream force-pushed the feature/register-new branch from 4ced188 to 6509e20 Compare September 8, 2025 11:04

TigerInYourDream force-pushed the feature/register-new branch from 19d1220 to e070f6f Compare September 10, 2025 14:28

TigerInYourDream added 4 commits September 19, 2025 11:08

add reset_screen_state after register success and NavigateToLogin

de8e5f6

Signed-off-by: Alvin <zyzzz0928@gmail.com>

Merge branch 'main' into feature/register-new

7fbf5d6

fix: Reset dock state flag on logout to prevent tab restoration

4b7f52b

Copilot AI review requested due to automatic review settings November 12, 2025 02:42

Copilot started reviewing on behalf of TigerInYourDream November 12, 2025 02:42 View session

Copilot finished reviewing on behalf of TigerInYourDream November 12, 2025 02:45

Copilot AI reviewed Nov 12, 2025

View reviewed changes

TigerInYourDream added 6 commits November 12, 2025 11:21

Merge branch 'origin/new_design' into feature/register-new

a169504

Revert "Merge branch 'origin/new_design' into feature/register-new"

35642a3

This reverts commit a169504, reversing changes made to 2f747bc.

Fix register screen macros after reverting new_design

989e267

Restore non-registration files to origin/main state

81aa921

Polish registration docs and UIA handling

74c53e8

Add registration token UI and keep SSO pending

33dfe0e

Signed-off-by: Alvin <zyzzz0928@gmail.com>

Merge branch 'main' into feature/register-new

fe502d0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Feature/register Support new account creation/registration #579

Feature/register Support new account creation/registration #579

TigerInYourDream commented Sep 5, 2025 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

Copilot AI Nov 12, 2025

Uh oh!

TigerInYourDream commented Dec 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	// Use the user-provided registration token if available
	// NOTE: Registration token support is not exposed in the UI; this code path exists for completeness,
	// but users cannot currently provide a registration token via the UI.

-                        }
+                        }
+                        // NOTE: This string match is a best-effort approach.
+                        // If the SDK exposes a specific error type/variant for invalid registration token,
+                        // prefer matching on that instead of the error message string.
+                        // This may need to be updated if the SDK changes error messages.

	let register_button = self.view.button(id!(register_button));
	register_button.set_enabled(cx, true);
	register_button.reset_hover(cx);

-            // Check password strength - minimum 8 characters
-            if password.len() < 8 {
-                self.show_warning("Password must be at least 8 characters");
-                return;
-            }
+            // Check password strength - minimum 8 characters and complexity
+            if password.len() < 8 {
+                self.show_warning("Password must be at least 8 characters");
+                return;
+            }
+            if !password.chars().any(|c| c.is_ascii_lowercase()) {
+                self.show_warning("Password must contain at least one lowercase letter");
+                return;
+            }
+            if !password.chars().any(|c| c.is_ascii_uppercase()) {
+                self.show_warning("Password must contain at least one uppercase letter");
+                return;
+            }
+            if !password.chars().any(|c| c.is_ascii_digit()) {
+                self.show_warning("Password must contain at least one digit");
+                return;
+            }
+            if !password.chars().any(|c| !c.is_ascii_alphanumeric()) {
+                self.show_warning("Password must contain at least one special character");
+                return;
+            }

		// Don't save the session here - it will be saved when we convert to LoginBySSOSuccess
		// This avoids duplicate session persistence

Feature/register Support new account creation/registration #579

Are you sure you want to change the base?

Feature/register Support new account creation/registration #579

Conversation

TigerInYourDream commented Sep 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Key Features

Technical Implementation

UI/UX Improvements

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Key Changes

Reviewed Changes

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

TigerInYourDream commented Dec 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

TigerInYourDream commented Sep 5, 2025 •

edited

Loading