Some valid partial handles resolve to a PAR HTTP error instead of intended .bsky.social assumption #6

What is happening?#

Bluesky allows users to create handles with -, as long as it is not the first or last character of their subdomain. Examples:

freyja-lynx.bsky.social
da-reports.bsky.social‬

If a user with such a handle forgets to include .bsky.social, the intended flow where the login screen gracefully shows an error and asks the user to try again does not happen -- instead, the entire HTML element gets replaced with an error PAR HTTP response invalid, and the user needs to refresh the page in order to see the login form again.

How to reproduce#

Put any subhandle with a hyphen in the login box, and press Sign-In.

Potential fix#

Currently, auth_utils::validate_login_input tries to determine an incomplete AT-handle with the following predicate: if subject.chars().all(|c| c.is_alphanumeric())...

The simplest patch would look like this:

diff --git a/src/http/auth_utils.rs b/src/http/auth_utils.rs
index 1cf1e87..f5dafb9 100644
--- a/src/http/auth_utils.rs
+++ b/src/http/auth_utils.rs
@@ -1,3 +1,5 @@
+use std::ascii::AsciiExt;
+
 use crate::http::errors::LoginError;
 
 /// Validates and filters incoming login requests.
@@ -22,7 +24,7 @@ pub(crate) fn validate_login_input(subject: Option<&str>) -> Result<Option<Strin
     }
 
     // Check if it looks like an incomplete AT-handle (alphanumeric with no dots)
-    if subject.chars().all(|c| c.is_alphanumeric()) && !subject.contains('.') {
+    if subject.chars().all(|c| c.is_alphanumeric() || c == '-') && !subject.contains('.') {
         return Err(LoginError::IncompleteHandle);
     }

I am not currently able to validate this with a local setup, but can try setting it up and verifying it works before submitting a PR.

The simple patch would also validate strictly incorrect subhandles as possibly valid ones -- if desired, I could write up a patch that would more thoroughly validate the subhandle to ensure that invalid ones like -freyja-lynx- are not treated as valid handles -- perhaps by adding a LoginError::InvalidHandle, and function(s) that verify a handle/subhandle would result in a valid atproto handle, as well as propagating that error up to the login screen gracefully.