Unable to create an Analytics account

Bug Description

Some users are reporting issues trying to create an Analytics account within Site Kit. As soon as they click on the “Create Account” they’re encountering a “You don’t have permission…” notice in a 403 page, slightly different in the 2 cases currently being investigated.

• You don’t have permission to access this document
• You don’t have permission to access /wp-admin/index.php on this server

This is similar to HostGator users (#3473) who encounter the below when pressing the same “Create Account” button:

Not Acceptable!
An appropriate representation of the requested resource could not be found on this server. This error was generated by Mod_Security.

This has been reproducible on a shared hosting site with HostGator - the below GET request below appears as a 406 console error: GET https://examplesite.com/wp-admin/index.php?action=googlesitekit_connect&nonce=eb61b0fd00&redirect=https%3A%2F%2Fsharedhg.cmsdevrel.com%2Fjames%2Fwp-admin%2Fadmin.php%3Fpage%3Dgooglesitekit-settings%23settings%2Fanalytics%2Fedit&additional_scopes%5B0%5D=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fanalytics.provision 406

This has also been reproducible with a Bluehost site as below:

The final URL with the error is below, on a support team test site: https://bluehost.cmsdevrel.com/wp-admin/index.php?action=googlesitekit_connect&nonce=bcf00eb8af&redirect=https%3A%2F%2Fbluehost.cmsdevrel.com%2Fwp-admin%2Fadmin.php%3Fpage%3Dgooglesitekit-module-analytics%26slug%3Danalytics%26reAuth%3Dtrue&additional_scopes[0]=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fanalytics.provision

Impacted users:

• https://wordpress.org/support/topic/analytics-no-permission-to-access-wp-admin-index-php/#post-14536207 | Open | SH info | openhost.co.nz
• https://wordpress.org/support/topic/403-forbidden-failed-to-create-a-new-analytics-account/#post-14535460 | Open | SH info | HostPress
• https://wordpress.org/support/topic/could-not-create-ga-account-via-site-kit-mod_security/ | Open | No SH info | Bluehost (This one specifically references ModSecurity)

Steps to reproduce

1. Setup Site Kit
2. Connect the Analytics module and choose to “Create a new account” as opposed to selecting a pre existing account
3. Error encountered

As a temporary workaround for those impacted please create a new Analytics account and Universal type property from analytics.google.com. After doing so connect the Analytics module within Site Kit, using that newly created account and property.

Additional Context

• PHP Version: This started to occur in early June (Site Kit 1.33.0)
• One user provided a video of their experience within their Site Health information
• While untested with the same hosting provider so far we have been able to recreate the ModSecurity issue for Hostgator users, with a console error added to that issue.
• Possible ModSecurity changes that may be impacting setup

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The getConnectURL selector of the core/user store should be modified so that if additionalScopes are requested, each scope is rewritten if, and only if it starts with http(s):// – the first character should be replaced with a g to become gttp(s)://
• On the server side, OAuth_Client::get_authentication_url should be updated to undo this replacement (restoring the original h) for any passed $additional_scopes (if and only if the scope begins with gttp(s)://) so that scopes are set on the client using the proper values
• Appropriate test coverage should be added to cover these changes

Implementation Brief

• In getConnectURL() of assets/js/googlesitekit/datastore/user/user-info.js

https://github.com/google/site-kit-wp/blob/04a3fa665bc220fc01be050c803404d401903b0c/assets/js/googlesitekit/datastore/user/user-info.js#L319

For each additionalScope, replace a starting http:// with gttp:// and a starting https:// with gttps:// Add a comment that we do it to get around a ModSecurity rule that has been causing issues on a few hosting providers.

Now on the server side we undo the change

• In get_authentication_url() of includes/Core/Authentication/Clients/OAuth_Client.php https://github.com/google/site-kit-wp/blob/04a3fa665bc220fc01be050c803404d401903b0c/includes/Core/Authentication/Clients/OAuth_Client.php#L632

Iterate the $additional_scopes replacing a starting gttp with http

Test Coverage

• Update phpunit/integration/Core/Authentication/Clients/OAuth_ClientTest.php test_get_authentication_url()
• Update assets/js/googlesitekit/datastore/user/user-info.test.js selectors > getConnectURL

Visual Regression Changes

QA Brief

• This issue changes the way additional oAuth scopes are requested from the client side to the local WP server through our wp-admin/index.php?action=googlesitekit_connect URL specifically
• This URL is used when connecting through oAuth, but the changes here are specific to when additional scopes are requested, such as when creating an Analytics account, property, or view or creating a Tag Manager container (if the scope has not already been granted)
• Start with a fresh Site Kit setup (does not need to be new site)
• Activate Analytics
• Select Set up a new account and submit -----> this is where the error would happen before – if you see the Google oAuth screen, then the changes here have worked
  • Make sure the relevant new scope is requested (although the following action would fail anyways if not)
• Everything else should work as normal

Changelog entry

• Fix a problem for some hosts where requests for Analytics account creation or other on-demand permissions were blocked.

[aaemnnosttv]

We’ve identified the cause to be related to Mod Security rules which block requests that have query args that begin with a URL, which is why this is flagged when creating a new account because Site Kit needs to request an additional oAuth scope to do this. In this case, the scope which is being passed in the query parameter is https://www.googleapis.com/auth/analytics.provision which is of course a valid URL but not really used as an actual destination, but the way authentication scopes are defined.

The same problem would happen for users with such hosts when trying to create a property or profile as well, so I’ll update this issue to not be account creation specific.

As @ivankruchkoff mentioned, we have a solution that we’ve tested on 9 domains that we know of that have been affected and they all worked using the suggested approach. Moving this forward to ACs 👍

[ivankruchkoff]

Searching a bit more in-depth for error messages, the summary here is that these are all related to server configuration setup. In all cases the best course of action is to raise a ticket with the hosting provider as their environment has some security settings that prevent working functionality of the WordPress sites.

One potential fix that is reported in several places is disabling mod_security for the site via the .htaccess, however that comes with its own set of risks and may not even be possible as the hosting provider may block this option, https://stackoverflow.com/a/58634971

The 406 error again indicates it is a WAF (Web Application Firewall) that is blocking the requests.

Likewise when browsing https://fareupthere.com/blog//?rest_route=/ - the link is pointing to a sucuri.net resource, they make a WAF for WordPress - https://sucuri.net/website-firewall/wordpress-firewall/ and so that product is misattributing the traffic as some sort of an attack.

I suggest in all of these cases that the user facing the issue raises a support ticket with their hosting provider with the exact set of repro steps, and ideal a URL that isn’t working, e.g. https://fareupthere.com/blog//?rest_route=/ so that the hosting provider can advise a fix for the issue, or update their hosting platform to not block this legitimate traffic.