Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.42k stars 1.99k forks source link

Domains: Add GSuite/Office365/Zoho - make TXT verif record optional? #23139

Open sophiegyo opened 6 years ago

sophiegyo commented 6 years ago

[Newbie/Trialmattician here, apologies in advance for errors in the post]

Enhancement:

When adding G Suite, Office 365 or Zoho to a domain would it be possible to make adding the TXT verif optional? Calypso > Domains > [example.com] > Name Servers and DNS > add [screenshot]

Currently it needs either a real or dummy TXT record (eg MS=ms12345678).

Context: I had a Happychat session (1999266-hc) with a user who had received some slightly confusing instructions from GoDaddy, who was providing their Office 365 email; and it was a learning experience for me too since I hadn't added email that way before.

The instructions the user was given definitely don't match up to our own support docs - and if they're not really given, or told how to get, the TXT verification record, it's a #painpoint which could be avoided.

Asked for help in Slack, chatted with @ehti (Slack archive begins here and ends here) who taught me about the dummy string, and suggested opening this issue.

klimeryk commented 6 years ago

Thanks for reporting, @sophiegyo! Looks like this might be duplicate of https://github.com/Automattic/wp-calypso/issues/21640?

ehti commented 6 years ago

ooh, nice catch @klimeryk . Though not sure if making the TXT record optional for all services (not just G Suite) should stay here or closed in favor of that.. your call.

It does come up pretty often (when someone wants to set Office 365 records, for example..).

klimeryk commented 6 years ago

TBH, we should just detect that the domain is already verified for the given service and just not show the input field for the token (or make it optional, in case someone needs to input an updated token?).

ehti commented 6 years ago

@klimeryk I don't think we can check if a domain is verified with G Suite/Zoho/O365 etc.

So yes - making it optional would be the best route IMO (with the field label also saying optional, so users aren't too confused).

Also, considering the issue in p2MSmN-6ro-p2 , I'd even say that we don't need to validate if the token format is correct. That's user's responsibility, and additional burden on us to keep track of how the token format is changing for each service.

klimeryk commented 6 years ago

I agree that it can totally change - as seen here. But we have to remember that this is a very asynchronous and "esoteric" action for the user. They want to set up their email - so they buy G Suite or Zoho and now they need to set up these magical "DNS records". So they end up on this view. If we make the token field optional, my guess will be that most of the users will just skip supplying it - or will input the incorrect value (like just the token, without the MS= part for O365). Because to them, it's not obvious how this works. And when they go back to Zoho and try to verify their domain, it will tell them it's not set up correctly, they come back to our support, we miss the fact that there's no valid TXT record, tell them they just need to wait (because DNS propagation can take some time), etc.

Instead, we should guide the user as much as possible. That means introducing validation when we can. Since the inception of this feature, this is the first report that there were problems validating the token. So, I wouldn't jump ship just now.

As for checking if a domain is verified - unless I'm mistaken how it's done, at least for G Suite, we can totally do that. We just check for a TXT record on the root domain that has a value that starts with google-site-verification. Of course, we have no idea if it's the correct token, but it should be in the vast majority of cases. Zoho is, IIRC, more problematic, cause they use unique CNAME records, but since it's our nameservers, we can easily enumerate all the subdomains and search for ones that look like zhxxxxxxxx.example.com (where x is a number).

That's user's responsibility, and additional burden on us to keep track of how the token format is changing for each service.

As mentioned above, I'd say that's at least our responsibility as well. We are offering a view that promises (implicitly) to help set up their email account. We should build it in a way that prevents common mistakes.

ehti commented 6 years ago

As for checking if a domain is verified

You can get a domain verified and then remove its TXT record - that's what leads to many confusing cases with Office 365 emails: People wanting to use their existing O365 email service with already verified domains, in quite a few cases purchased from 3rd parties like GoDaddy. And they have no TXT records to provide or at least nothing is in their DNS editor.

And we force-ask for it, that too in a particular format.. and in turn HEs direct users back to their registrar support, who don't have the TXT record, and the circle continues.

So - maybe make it optional with a message indicating verification record is needed if the domain isn't verified.

klimeryk commented 6 years ago

@ehti sorry for the late reply. OK, let's go with the optional token and show an alert when there are no TXT records - in which case we'll show a dialog asking the user if they're sure they've verified the domain (with appropriate links to documentation at Google/O365/Zoho). Sounds good?

klimeryk commented 6 years ago

When working on this, one might also look into improving the issue raised in https://github.com/Automattic/wp-calypso/issues/24126 - namely, if there is a TXT record present, we could try extracting the token from it and showing on this screen, pre-filled.

Lochlaer commented 5 years ago

Just wanted to post a quick follow up that while we wait for this one to be fixed/resolved, I posted a workaround in p6WzvN-cO-p2.

github-actions[bot] commented 3 years ago

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

liviopv commented 3 years ago

Bringing this up again because Google Workspace seems to be no longer using a TXT record for verification. Instead, it users an MX record by default.

A sample MX Record value would be l62cuqt32vfbkqdbrqmsakeqaptsp5qgzayeyd43cv7qs3mqmi7q.mx-verification.google.com with Priority 15.

Here's a screenshot of the new instructions from the Google Workspace console:

Screenshot Screenshot: https://d.pr/i/KTvRly

cc @klimeryk since you were the last dev to have interacted with this issue

github-actions[bot] commented 3 years ago

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.