ProxyMapService: ParseUsernameParameters

We’re excited to announce a new, optional feature in the ProxyMapService application. This feature enhances the flexibility of the authentication process by allowing you to simplify username validation.

The Challenge: Managing Complex Usernames

Sometimes, proxy usernames need to encode more information than just the account identifier.

For example, a proxy might look like this:

http://user-zone-custom-region-US-session-1234567-sessionTime-5:1111@127.0.0.1:8888

Username part of the proxy is user-zone-custom-region-US-session-1234567-sessionTime-5.

While this format might be necessary for other parts of the system or for identification, it complicates the standard authentication process by requiring the system to ignore the extra parts (zone, region, session, etc.) and focus solely on the actual username.

The Solution: Introducing ParseUsernameParameters

To address this need for cleaner authentication, we’ve introduced a new configuration parameter called ParseUsernameParameters. This boolean parameter resides within the Authentication section of the appsettings.json file.

• Parameter Name: ParseUsernameParameters
• Allowed Values: true or false (default is false)

What Does This Parameter Do?

When set to true, the ProxyMapService will parse the username string during authentication. It splits the username using the hyphen (-) delimiter. Crucially, only the first segment (the part before the first hyphen) is used for the authentication check. The remaining segments are ignored.

How It Works (Example)

Let’s take a look at the authentication logic with ParseUsernameParameters=true:

1. Input Username (part of the proxy):

   "user-zone-custom-region-US-session-1234567-sessionTime-5"

2. Authentication Logic (with ParseUsernameParameters=true):

   • The username string user-zone-custom-region-US-session-1234567-sessionTime-5 is split using the - character.
   • The resulting parts are: ["user", "zone-custom-region-US-session-1234567-sessionTime-5"]
   • Authentication Check: The system compares the first part, user, to the configured Username value (e.g., "user" from the example config). The rest of the parts are completely ignored for authentication.

Configuration Example (appsettings.json)

Here’s how you would enable this feature in your appsettings.json:

{
  "Authentication": {
    // ... other authentication settings ...
    "Required": true,
    "Verify": true,
    "ParseUsernameParameters": true,
    "Username": "user",  // This is the base username to compare against
    "Password": "1111"    // Password
  }
}