Test Cases

Test Case 1.1: Valid Credentials

Objective Verify that users can successfully authenticate with valid credentials.

Test Steps

1. Navigate to the login page.
2. Enter valid username and password.
3. Submit the login form.

Expected Results

• Authentication succeeds.
• User is redirected to the dashboard (e.g. https://demo1.dashboard.phpr.link/en).
• The currentUser token is properly generated.

Test Case 1.2: Invalid Username Format

Objective Verify the system rejects login attempts with an invalid username format.

Test Steps

1. Navigate to the login page.
2. Enter a badly formatted username (e.g. "a user").
3. Enter a valid password.
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• Username format error message is displayed (“Username format is invalid.”).

Test Case 1.3: Invalid Password

Objective Verify the system rejects login attempts with an incorrect password.

Test Steps

1. Navigate to the login page.
2. Enter a valid username.
3. Enter an incorrect password.
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• A generic credential error message is displayed.

Test Case 1.4: Non-existing User

Objective Verify the system handles login attempts for non-existing users properly.

Test Steps

1. Navigate to the login page.
2. Enter a username that doesn’t exist in the system.
3. Enter any password.
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• A generic credential error message is displayed (does not reveal whether the account exists).

Test Case 1.5: Empty Username

Objective Verify the system rejects login attempts with an empty username.

Test Steps

1. Navigate to the login page.
2. Leave the username field empty.
3. Enter any password.
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• A username-required error message is displayed.

Test Case 1.6: Empty Password

Objective Verify the system rejects login attempts with an empty password.

Test Steps

1. Navigate to the login page.
2. Enter a valid username.
3. Leave the password field empty.
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• A password-required error message is displayed.

Test Case 1.7: Both Username and Password Empty

Objective Verify the system rejects login attempts with both username and password empty.

Test Steps

1. Navigate to the login page.
2. Leave the username field empty.
3. Leave the password field empty.
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• Both the username-required and password-required error messages are displayed.

Test Case 1.8: Authentication Performance

Objective Verify the login process performance is within acceptable limits.

Test Steps

1. Navigate to the login page.
2. Enter valid username and password.
3. Start a timer.
4. Submit the login form.
5. Stop the timer upon redirection to the dashboard.

Expected Results

• The authentication process completes within 5 seconds.
• User is redirected to the dashboard.

Test Case 2.1: Intended Destination Redirect

Objective Verify users reach their intended destination after login.

Test Steps

1. Attempt to access an app while logged out (e.g. https://demo1.email.phpr.link/en).
2. Confirm redirection to the login page.
3. Complete authentication.

Expected Results

• The original URL is preserved during the redirect to login.
• After successful authentication, the user is redirected to the original URL.
• No redirect loops occur.

Test Case 2.2: Redirect When Token Is Invalid or Expired

Objective Verify users are redirected to the login page when their token is invalid or expired.

Test Steps

1. Attempt to access an app with an expired token (e.g. https://demo1.email.phpr.link/en).
2. Confirm redirection to the login page.
3. Complete authentication.

Expected Results

• The original URL is preserved during the redirect to login.
• After successful authentication, the user is redirected to the original URL.
• No redirect loops occur.

Test Case 2.3: Redirects to the Same Environment

Objective Verify users are redirected back to the same environment (e.g. dev) when going from app to login and back.

Test Steps

1. Attempt to access an app while logged out on a specific environment (e.g. dev).
2. Confirm redirection to the login page.
3. Complete authentication.

Expected Results

• The original URL is preserved during the redirect to login.
• After successful authentication, the user is redirected to the original URL.
• No redirect loops occur.
• The environment is maintained (e.g. dev).

Test Case 2.4: Redirects to the Same Tenant

Objective Verify users are redirected back to the same tenant when going from app to login and back.

Test Steps

1. Attempt to access an app while logged out for a specific tenant.
2. Confirm redirection to the login page.
3. Complete authentication.

Expected Results

• The original URL is preserved during the redirect to login.
• After successful authentication, the user is redirected to the original URL.
• No redirect loops occur.
• The tenant is maintained.

Test Case 3.1: CSRF Protection

Objective Verify the login form is protected against Cross-Site Request Forgery.

Test Steps

1. Navigate to the login page and inspect the form.
2. Edit the CSRF secret cookie.
3. Attempt login with an invalid CSRF token.
4. Delete the CSRF secret cookie.
5. Attempt login with a missing CSRF token.

Expected Results

• A CSRF token is present in the form.
• Login fails with an invalid token.
• Login fails with a missing token.

Test Case 3.2: Rate Limiting

Objective Verify the system implements rate limiting to prevent brute-force attacks.

Test Steps

1. Attempt multiple login requests in rapid succession.
2. Note the system’s behavior and response codes.
3. Wait for the rate limit to reset.
4. Attempt login again.

Expected Results

• The system begins returning 429 Too Many Requests.
• Error messages indicate rate limiting.
• After the cooldown period, login attempts are permitted again.
• Rate limits are properly tracked (by IP, user, or both).

Test Case 3.3: SQL Injection Protection

Objective Verify the login form is protected against SQL Injection attacks.

Test Steps

1. Navigate to the login page.
2. Enter SQL injection strings in the username and password fields (e.g. ' OR '1'='1'; --).
3. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• No SQL errors are displayed.
• A generic credential error message is displayed (e.g. “Invalid username or password.”).

Test Case 3.4: XSS Protection

Objective Verify the login form is protected against Cross-Site Scripting (XSS) attacks.

Test Steps

1. Navigate to the login page.
2. Enter XSS payloads in the username and password fields (e.g. <script>alert('XSS')</script>).
3. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• No scripts are executed.
• A generic credential error message is displayed (e.g. “Invalid username or password.”).

Test Case 3.5: Show/Hide Password Toggle

Objective Verify the show/hide password functionality works correctly.

Test Steps

1. Navigate to the login page.
2. Enter a password in the password field.
3. Click the show-password toggle and verify the password is visible.
4. Click the hide-password toggle and verify the password is masked again.

Expected Results

• The password is visible when the show toggle is clicked.
• The password is masked when the hide toggle is clicked.

Test Case 4.1: Very Long Username and Password

Objective Verify the system handles very long username and password inputs.

Test Steps

1. Navigate to the login page.
2. Enter a very long username (e.g. 1000+ characters).
3. Enter a very long password (e.g. 1000+ characters).
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• Appropriate error messages are displayed indicating input length issues.

Test Case 4.2: Case Sensitivity

Objective Verify the username and password fields are case sensitive.

Test Steps

1. Navigate to the login page.
2. Enter a valid username with different casing (e.g. "User" instead of "user").
3. Enter a valid password with different casing (e.g. "Password" instead of "password").
4. Submit the login form.

Expected Results

• Authentication is rejected.
• User remains on the login page.
• A generic credential error message is displayed.

Test Case 5.1: Forgot Password Link

Objective Verify the “Forgot Password” link navigates to the correct page.

Test Steps

1. Navigate to the login page.
2. Click the “Forgot Password” link.

Expected Results

• User is redirected to the password recovery page (e.g. https://demo1.login.phpr.link/en/forgot-password).

Test Case 5.2: Report an Issue Link

Objective Verify the “Report an Issue” button opens the report dialog.

Test Steps

1. Navigate to the login page.
2. Click the “Report an Issue” button.

Expected Results

• A dialog/modal for reporting an issue is displayed.

Test Case 5.3: Accessibility — Keyboard Navigation

Objective Verify that all interactive elements on the login page are accessible via keyboard navigation.

Test Steps

1. Navigate to the login page.
2. Use the Tab key to navigate through all interactive elements (input fields, buttons, links).
3. Use Enter/Space keys to activate buttons and links.

Expected Results

• All interactive elements are reachable using the Tab key.
• Buttons and links can be activated using Enter/Space keys.