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

[Michael_DeRosa]

Hi Sanford Whiteman that would be great. I'll try to set up now. I can give you an uberconference link.

[SanfordWhiteman]

JoinMe is better for me. I'm starting join.me/figureone now.

[Michael_DeRosa]

Ok, I'm on join.me/figureone. I don't see you, however. Let me know if there's a different link I should follow.

[SanfordWhiteman]

Case anyone else is paying attention, Michael & I looked at this offline and determined that it was only happening in Chrome 78 on one Win 10 PC (and not happening in Internet Explorer on that same machine) and decided to chalk it up to some intermediate inspecting firewall at the company. Testing the exact same combo of Windows 10 + Chrome 78 in my lab, everything works fine (as it did on other PCs within the same company).

Much as I wanted to get the exact cause, we didn't have administrator access to the PC nor a liaison with their IT.  But it's not anything to worry about IMO.

[Michael_DeRosa]

[Michael_DeRosa]

Hi Sanford Whiteman‌, we intend to deploy some Marketo-related updates to our production site this evening, but are hesitant with one of our test users still getting this 403 error. Are there any other files we can provide for troubleshooting purposes?

[SanfordWhiteman]

I don't know about files but if you want to get on a screenshare (on that person's machine) I can take a look.

[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?

[Michael_DeRosa]

No, we don't get the CloudFlare reCAPTCHA-protected page for the following resources accessed from the browser's url bar (nor any other urls we've tried): 

http://go.crowncastle.com/js/forms2/js/forms2.min.js

https://go.crowncastle.com/js/forms2/js/forms2.min.js

https://go.crowncastle.com/index.php 

https://go.crowncastle.com/index.php/form/getForm?munchkinId=832-NON-210&form=1102 

https://go.crowncastle.com

I should add that this user, earlier in the week, was getting the expected form-load behavior in IE. But some time within the past few days, this 403 error began occurring in IE too (and is now persisting). In addition, we have a separate Marketo instance at go.fiber.crowncastle.com referenced by a separate site via Marketo embedded forms, and this user is getting a 403 from that instance as well (although I can't say for certain when that started happening). This other site is on SSL.

[SanfordWhiteman]

Can you post a screenshot of the 403 response (the full body)?

[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.