Forms2.min.js intermittently giving 403 for some users

[Anonymous]

Hi all,

We use the Marketo forms 2.0 on our website. On a few machines we have seen an error that reads:

When most people visit our site we do not see this error in the console, however, for at least 2 machines we've seen this. We've been able to fix it on each of the machines by having them physically type in https://app-sji.marketo.com/js/forms2/js/forms2.min.js into the browser. After that point the forms load for them. For all forms we are using the embed code provided by Marketo. Has anyone seen similar issues / know of a reasonable workaround? Is it necessary to edit the embed code provided by Marketo to have it work for all users all the time?

Stephen Ross,

Intradiem

[SanfordWhiteman · Accepted solution]

Certainly this isn't a regular situation. Note that what you're manually typing is the https:// URL, which isn't the first URL the browser requests when running from a non-SSL site.

On a non-SSL site, in a browser that has never visited your Marketo pod before, the browser will request the http:// version and will receive a redirect from the Marketo server to the https:// version.  On subsequent visits the browser will no longer request the http:// version for Marketo but will request the https:// version only. 

Because of the distinctly different expected behavior between the first and subsequent visits, this specific case can be very difficult to troubleshoot, because the http->https internal redirection persists in Incognito/Private windows as well.

I would recommend you hard-code https:// (instead of the protocol-relative //) and see if you can repro the problem.

[Anonymous]

Hi Sanford.

I will make this as the correct answer for two reasons:

1. Going to the https:// location has fixed the problem for those for which it has occurred.
2. I have reason to believe that our security platform, Sophos, which has been installed on each of the machines which have had this issue, may be interfering with the marketo files trying to load in the background.

[SanfordWhiteman]

Thanks for the update. There could indeed be a malfunctioning antivirus signature/heuristic affecting this. Can't see what policy it would be trying to enforce, though.

[Michael_DeRosa]

Hi Sanford, we have a user who is running into this same 403 error. This is on a non-SSL site, where the reference to the forms2 js does not use https (and uses a Marketo domain alias for which SSL has been set up). Simply referencing the forms2 js script over https doesn't fix it for them (nor does having them put the https url in their browser). Of about 10 users we've tested, this is only happening to one and it is persistent for that user. Do you have any other insights as to why this may be happening or a possible work-around?

[SanfordWhiteman]

Are they getting a CloudFlare page when they go straight to the URL (in a new tab)?

[Michael_DeRosa]

No they are not.

[SanfordWhiteman]

What are the other characteristics of this device (OS version, browser, browser version)? What's the real URL? Does it happen in a new incognito window in that same browser?

Certainly a 403 Access Denied should not be happening selectively.

[Michael_DeRosa]

Sanford Whiteman here are the answers to your latest questions, and see below for more info.

• What are the other characteristics of this device (OS version, browser, browser version)?  Windows 10, Chrome 78.0.3904.97
• What's the real URL?  (see more info below)
• Does it happen in a new incognito window in that same browser?  Yes

I gave some bad information in my original post. The 403 is in response to the following request which gets called when the MktoForms2 loadForm function executes (not the loading of the forms2 js) from the page at http://stage-crowncastle-v2.cphostaccess.com/contact-us-sales-form

MktoForms2.loadForm("https://go.crowncastle.com", "832-NON-210", 1102, function (mktoForm) { ... });‍‍

Here is the request and 403 response details:

General:
Request URL: https://go.crowncastle.com/index.php/form/getForm?munchkinId=832-NON-210&form=1102&url=http%3A%2F%2Fstage-crowncastle-v2.cphostaccess.com%2Fcontact-us-sales-form&callback=jQuery112408175449259215843_1574266740246&_=1574266740247
Request Method: GET
Status Code: 403
Remote Address: 104.17.72.206:443
Referrer Policy: no-referrer-when-downgrade

Response Headers:
cache-control: max-age=2
cf-chl-bypass: 1
cf-ray: 538bc770db3eef0e-MIA
content-encoding: gzip
content-type: text/html; charset=UTF-8
date: Wed, 20 Nov 2019 16:25:18 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 20 Nov 2019 16:25:20 GMT
server: cloudflare
set-cookie: __cfduid=d30ba2277e46b30e81f67881d7ad1fd821574267118; expires=Fri, 20-Dec-19 16:25:18 GMT; path=/; domain=.go.crowncastle.com; HttpOnly
set-cookie: __cf_bm=5be1cf3fc4ff37beaecc56f1aa116f5e68a06339-1574267118-1800-ASbbvngNe6zLLechOjYJSeqEB/A+Ta6jzI1HEIB60CoiJrwrnmNMloub0d4k+pg71trBQOUrH5shhlsbvEPlnKE=; path=/; expires=Wed, 20-Nov-19 16:55:18 GMT; domain=.go.crowncastle.com; HttpOnly
status: 403
vary: Accept-Encoding
x-frame-options: SAMEORIGIN

Request Headers:
:authority: go.crowncastle.com
:method: GET
:path: /index.php/form/getForm?munchkinId=832-NON-210&form=1102&url=http%3A%2F%2Fstage-crowncastle-v2.cphostaccess.com%2Fcontact-us-sales-form&callback=jQuery112408175449259215843_1574266740246&_=1574266740247
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
referer: http://stage-crowncastle-v2.cphostaccess.com/contact-us-sales-form
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Query String Parameters:
munchkinId: 832-NON-210
form: 1102
url: http://stage-crowncastle-v2.cphostaccess.com/contact-us-sales-form
callback: jQuery112408175449259215843_1574266740246
_: 1574266740247

[SanfordWhiteman]

And if you try to get the file directly, then do you get the CloudFlare reCAPTCHA-protected page?