Add melio.com password rules and shared credentials with meliopayments.com

[fluctus]

Overall Checklist

• I agree to the project's Developer Certificate of Origin
• The top-level JSON objects are sorted alphabetically
• There are no open pull requests for the same update

for shared-credentials.json

• There's evidence the domains are currently related (SSL certificates, DNS entries, valid links between sites, legal documents etc.)
• If using shared, the new group serves login pages on each of the included domains, and those login pages accept accounts from the others.

---

Shared Credentials: melio.com and meliopayments.com

Melio operates under two domains:

• melio.com - primary domain (login at accounts.melio.com)
• meliopayments.com - legacy domain (login at app.meliopayments.com)

Both domains serve login pages that accept the same user credentials. The top-level domain melio.com redirects to meliopayments.com. Both domains are owned and operated by Melio Payments, Inc.

I am a developer at Melio and can confirm these domains share a credential backend.

[rmondello]

Hiya @fluctus! The motivation for the shared credentials rule makes sense for me, but the password requirements cited seem pretty "obviously" met by most major password managers without a quirk. Did you see anything different, or were you just adding the rule because you could? (All answers are OK. I just wanna talk about this!)

[fluctus]

Hiya @fluctus! The motivation for the shared credentials rule makes sense for me, but the password requirements cited seem pretty "obviously" met by most major password managers without a quirk. Did you see anything different, or were you just adding the rule because you could? (All answers are OK. I just wanna talk about this!)

Hey @rmondello! thanks for reviewing!

Good question! The main motivation is the required: special rule. Safari's built-in password generator creates passwords in a format like fuvDaj-romke5-nyxbyh where the hyphens are delimiters, but depending on the validator's definition of "special character," those hyphens may or may not qualify. Our backend validates against a specific set of special characters, and without the quirk, there's a real risk of Safari generating a password that it considers strong but our server rejects at signup.

We actually hit this scenario during testing - the default generated passwords would sometimes fail our validation. Adding the explicit rules ensures Safari generates passwords that are guaranteed to pass on the first try, rather than leaving users confused by a rejection of a password they didn't even type.

The shared credentials entry (melio.com / meliopayments.com) is arguably the more important part - we serve login from both accounts.melio.com and app.meliopayments.com with the same backend, so credentials need to be shared across both domains.

[fluctus]

Hey @rmondello, just checking in - did my reply above address your question? Happy to provide more details or adjust anything if needed. Thanks!

[rmondello]

@fluctus "special" includes all special characters, including -. I highly recommend that you specify all special characters explicitly, like many other rules do.

That said, you said, "our backend", which means that you run this website. In that case, there's no need to add a quirk! Look at the HTML information on this page: https://developer.apple.com/documentation/security/customizing-password-autofill-rules

[fluctus]

Thanks @rmondello! I've updated the PR to remove the password-rules.json entry and keep only the shared credentials entry for melio.com and meliopayments.com. I'll also add the passwordrules attribute to our HTML inputs as you suggested.

[rmondello]

Thanks @fluctus!