Site Address accepts emails when trying to log in using an URL

[eduardozulian]

I've seen a few cases when users are getting an incorrect username/password message but they are sure that the credentials are correct. What is probably happening (example on 3729175-zen) is that users type their own email instead of their site URL. And for some reason, we accept that if the part after the @ is a WP site.

Expected behavior

To see an error message explaining to the user that this field is for site URLs, not emails.

Actual behavior

1. If you type an email (valid or not) followed by a domain that is not pointing to a WP site, you'll see the 'The site at this address is not a WordPress site` message.
2. If you type an email (valid or not) followed by a domain that IS pointing to a WP site, we will let the user proceed and ask them to log in (to an email).

Image from https://github.com/wordpress-mobile/WordPress-iOS/issues/15868 :

Steps to reproduce the behavior

1. Open the app while unlogged
2. Click on Enter your existing site address
3. Type something like http://[email protected]. Make sure that example.com is a WP site.

Tested on iPhone 7, iOS 14.4, WPiOS 16.5 and 16.6

[eduardozulian]

Here's an example: 3783275-zen

[designsimply]

Making it so the "Site address" field will not validate if an @ symbol is included in the URL field could help, however, I will also note that in many of these cases users may still need help understanding very basic things such as the difference between an email address and a site address or help figuring out what their website address is at a very basic level because they are entering completely wrong information (as in the case of 3783275 where the person entered a wordpress.org address and it's not possible for them to get that).

@renanferrari could you help us with a quick review and recommendation for this case. Do you think it would be worth updating the validation for the site address field to make it so "http://[email protected]" does not count as a valid url? Would this likely be a quick fix or take some time to investigate and update?

For reference, this is the error shown if you enter an email into the site address field	Sometimes people try to get around that by adding http:// to the front of an email address	These users either do not appear to be able to find the related help tip or maybe they don't understand it?

^{Tested with WPAndroid 16.8-rc-1 on Pixel 3 Android 11.}

[renanferrari]

Hey 👋 This is an interesting one!

The reason we accept a @ as part of the URL is because we are currently using a validator that follows the standards defined by the RFC 3987, which is basically the document that says what should be considered a valid URL and what should not. Despite what we might think, there's a really broad range of valid URLs that are covered by these standards (you can test some yourself on this link).

Long story short, yes, believe it or not http://[email protected] is a valid URL. And [email protected] is not 🤷‍♂️

That said, we could definitely try to add some logic to validate whether or not a URL is a valid WordPress URL. This should be doable and might even be a trivial change code-wise, but I'd say that unless we already have some documentation on this that I'm not aware of (not very unlikely), it would probably take a while to investigate and make sure we have all the valid cases covered.

For now, I'd suggest leaving it as it is and maybe trying to tackle this from an UX angle, specially considering the points raised by @designsimply above and the fact that those screens have plenty of space to work with.

[designsimply]

@renanferrari Ah! RFC 3987! 😁 Thank you for checking in on this and adding excellent notes.

@eduardozulian after some investigation, it appears that ruling out site addresses like http://[email protected] is not a super straightforward change may not cover the use cases you've raised. I'm keen to make sure your suggestion gets seen and evaluated. Would you like to keep this case open in order to see if you can find some additional cases of confusion around this issue? Adding specifics and increasing the numbers of cases here in the comments would help sway the issue to a higher priority. For specifics on what to note, I think user quotes from users explaining the problem and a shorthand link to the ticket would be a great start.

[eduardozulian]

@designsimply most of the cases I've seen came from the logs directly when there was a volley error trying to access something like http://[email protected]/xmlrpc.php. So my assumption is that users simply don't know what went wrong and contact support saying they "can't log in".

That said, let's keep it open for now then and I'll make sure to ping other guild members to collect a few reports!

[SiobhyB]

I'm just noting a conversation related to this at pbArwn-1Uo-p2#comment-2710, where more examples of users entering their email address into the form were found by searching our ticket system for tickets tagged origin:login-site-address e.g. 3833080-zen

In some of these cases, I get a sense that the users may be trying to set up sites or accounts from scratch, though it could also be the case that they're confused around the differences between email addresses vs. site addresses. I think it could be valuable to dive further into this.

[eduardozulian]

Another case in 3842207-zen

[zwarm]

There doesn't seem to be a way forward with this one yet. Our code fix options are not straight forward, nor has there been any progress made to address this from a User Experience perspective. @designsimply - Not sure how we should classify this for or where we should take it for a decision on forward movement? wdyt?

[ravishanker]

@designsimply What would you suggest to handle this from UX perspective? A few options we could try

• A hint inside the input field
• A help text outside the field
• A snackbar suggesting to check again if a @ symbol is detected

[thehenrybyrd]

@zwarm @ravishanker a UX enhancement could help here, though that does depend on people reading. 😬

I like this suggestion:

A snackbar suggesting to check again if a @ symbol is detected

Since we can't prevent using the @ symbol, we can at least say something like "it looks like that might be an email address - are you sure?" or similar.

[zwarm]

@thehenrybyrd @ravishanker

In theory I like the idea of a snackbar, but I'm not sure if it works as we are expecting.

I did a quick POC during my GK to try out a few show snackbar options and I'm not particularly fond of any of the results:

1. Showed the snackbar after the @ character had been entered. The messaging doesn't feel right because nothing has been typed past that character. See the video for this one.
2. Kept the snackbar visible on the view after the @ character was typed. The snackbar covers the Continue button, especially when the keyboard is open. A bit more work for this implementation, as we'd have to manage snackbar removal programmatically.
3. Showed the snackbar after tap of the Continue button. In this situation, we'd probably want verification from the user before continuing.

https://user-images.githubusercontent.com/506707/133329460-9b1fd4d8-f47a-4e67-8cea-4bb5ca69ae90.mp4

Perhaps we need to bring a designer into the conversation before we go any further.

[renanferrari]

After taking a second look at this, I have a few additional thoughts I want to share:

1. Most tickets I've seen with this issue so far are from WPiOS, which is still accepting emails into the site address field.
2. Out of the four tickets shared above, there's only one I can say for sure was actually caused by a WPAndroid user typing an address like http:///[email protected]:
   • 3842207-zen is a WPiOS ticket.
   • 3783275-zen seems to be a valid case of this issue.
   • 3833080-zen doesn't seem to have anything in the logs that points to an error in the Site Address screen. While there is an error involving an email address there, it seems to have happened in the Email screen.
   • 3842207-zen doesn't have any logs? I'm not sure if we delete logs for any reason or if I'm missing something.

@eduardozulian Do you have any other tickets you can share?

3. It's also important to note that while it's true that if we see something like https://[email protected] in the WPAndroid logs we can safely assume the user typed that themselves, this is not always true for WPiOS. That's because the app sometimes appends a http or https to the start of the provided URL as part of the process to resolve it. You can see this behavior in the video below:

https://user-images.githubusercontent.com/830056/135356848-6e29aba3-ee8c-4981-a60c-dd5a33667897.mov

---

I also tried to build a POC based on the ideas shared above, but instead of only detecting a @ and showing a Snackbar, I verify if the URL contains a valid email pattern and show a regular label with a link to the Email screen:

https://user-images.githubusercontent.com/830056/135357999-80711bee-f5ce-402b-a8f2-f568c110e348.mp4

I can't say I'm happy with the result, but maybe we can build from it if this still proves to be a relevant issue on WPAndroid (I pushed the code to this branch). Either way, I agree with @zwarm in that we should bring a designer into the conversation before moving forward.

[eduardozulian]

@renanferrari

I don't have any other reports at this time but I checked both 3833080-zen and 3842207-zen. For the first ticket I'm assuming this was likely just me pasting the wrong ticket link so I think we can just ignore it.

As for the missing logs, that also happened on the iOS side (3881292-zen and 3842207-zen) so there's some internal context for that: p1607469181111400/1607460779.096400-slack-C02A4RLLV

[dangermattic]

Thanks for reporting! 👍