Testcafe-hammerhead: iframe content is blocked by 'X-Frame-Options' set to 'sameorigin' directive (Workaround added)

[bennymeade]

Hello,

Tool versions:
"testcafe": "^0.23.3"
Chrome 74 (tested with FF also)
Mac OSX Mojave 10.14 (tested on Wins 10 also)

Summary:
An iframe on our website is coming from a 3rd party supplier, processing card payments. The iframe directive of X-Frame-Options is set to ‘sameorigin’ and this is working fine when tested manually in a normal browser instance.

But when running TestCafe the iframe is 'refused to connect', as TestCafe is serving the test site via a proxy server. The iframe directive is blocking the response content from being displayed, due to its ‘sameorigin’ security level.

I've asked the 3rd party if they can use 'allow-from' on the iframe directive, but that's not possible. So I need to figure out how to get TestCafe to view the iframe contents as this is a major blocker for us.

Run command:
$ npm run testChromeUi
"testChromeUi": "testcafe chrome tests/ --screenshots ./screenshots --screenshots-on-fails -e --allow-insecure-localhost --allow-running-insecure-content --dev --debug-on-fail",

Error:
Refused to display 'http://192.168.15.42:59242/g9fBtWYro!if/https://www.URL/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

[Farfurix]

Hello,

Unfortunately, this information is not sufficient to find the cause of the issue.

You are using an old TestCafe version. Please update your installation to v1.1.3. If it doesn't help, could you please provide us with a simple project (or public URL) illustrating this issue?

[bennymeade]

@Farfurix I've updated my TestCafe version, but unfortunately the same issue is occurring:
"devDependencies": {
"testcafe": "^1.1.3"
}

I'm not able to provide access to our test env and anyhow it's inside a private domain. But I will try to reproduce it on the live site with new code.

Update:
I've also been able to reproduce the issue by recording the steps with TestCafe Studio on the Live site. Which would be the easiest method for you to reproduce locally, because the live site has Captcha on it and my TC framework code won't be able to handle that.

Disclaimer: all test data provided here is public already.

Steps to reproduce:

• Launch TestCafe Studio with: https://www.sainsburys.co.uk/
• Click: Log in / Register
• Click: Groceries account
• Enter email address: [email protected]
• Complete Captcha
• Enter Password: Password1
• Click: Payment cards
• Click: Add a new payment card
• Enter payment card details (these are widely known Test Credit Card Account Numbers):
  -- Name
  -- Card: 4111111111111111
  -- Date 01/21
• Click: Add this card

Error seen:
Refused to display 'http://10.152.234.239:61333/r9cPy38jN!if/https://www.sainsburys.co.uk/webapp/wcs/stores/servlet/MyCardsAddReturnView?storeId=10151&langId=44' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

[Farfurix]

@bennymeade

Hello,

Thank you for the additional information. I've reproduced the issue under Chrome 74 / Windows 10. We need some time to investigate this issue using your credentials.

[bennymeade]

Thanks @Farfurix if you need any additional info for your investigation, I'm happy to provide it if possible.

[bennymeade]

Hi @Farfurix just to mention; I'm not sure why I opened this issue specifically under testcafe-hammerhead. I'm using testcafe. Once a fix arrives is it applied to latest testcafe version, as opposed to testcafe-hammerhead?

[miherlosev]

@bennymeade
 
Yes, you've created this issue in the testcafe repository. I moved it to the testcafe-hammerhead repository because the TestCafe problem is related to the module that is located in its repository.
 

Once a fix arrives is it applied to latest testcafe version, as opposed to testcafe-hammerhead?

No, it's not. I will write to you when the TestCafe version with the fix is available.

[bennymeade]

@miherlosev many thanks for the speedy replies.

[appendixshuffle]

We are facing same issue in our project and this is blocker for us too because our whole app is displayed in x-frame.

[Farfurix]

@appendixshuffle

Hello,

We need some time to investigate it. It would be great if you could provide us with a sample project to reproduce this issue without any credentials and CAPTCHA tests.

[bennymeade]

@Farfurix This is the work around we used for this issue:

Using TestCafe Mock we intercepted the POST request after submitting the payment form details.

We were able to achieve the intercepting using TC -d, --debug-mode, and from Dev Tools > Network locate the specific POST > view RESPONSE tab... this allowed us to extract the HTML code of the response.

We then removed the problem header res.headers['X-Frame-Options'] = ''.

This allows us to then simply click on the Continue button and get the payments card confirmation page as normal.

import { RequestMock } from 'testcafe';

const providerUrl = '/MyCardsAddReturnView';

const isProvider = ({ url, method }) => url.includes(providerUrl) && method === 'post'

// Dev tools with TC debugger paused on request - Response from file 'MyCardsAddReturnView' - Method 'POST'
// Request URL:http://192.168.0.22:58532/J0PruHvww!if/https://www.testenv.co.uk/MyCardsAddReturnView

const mockedPageHtml = `
<!doctype html>
<html>
   <body>
      <form action="MyCards" method="post" id="myCards" name="myCards" target="_parent"/>
         <input type="hidden" name="haveReturnedFromPaymentGateway" value="true">                  
         <p class="paymentGatewayIframeReturnEndPoint">Please select continue to add your card</p>
         <div class="formButton">
            <input class="buttonPrimary" type="submit" id="paymentGatewayIframeReturnSubmit" name="paymentGatewayIframeReturnSubmit" value="Continue" />
         </div>
         <script type="text/javascript" ></script>
      </form>
   </body>
</html>
`

export const unlockIframe = RequestMock()
  .onRequestTo(isProvider)
  .respond(async (req, res) => {
    res.headers['X-Frame-Options'] = ''
    res.statusCode = '200';
    res.setBody(mockedPageHtml);
})

[aleks-pro]

Hi @bennymeade ,

I'm happy to hear that you have found a workaround. It's a great idea to mock a response. But why do you mock the page's HTML? It looks like removing the 'X-Frame-Options' header should be sufficient to overcome the issue.
 
Also, I suggest discussing all the issues concerning this workaround in the StackOverflow thread you've created. It will help us process your questions more efficiently.

[bennymeade]

Only removing the 'X-Frame-Options'header was not enough in my scenario, because a blank page was returned in place of a payments confirmation page. The solution for this was intercepting the POST request after submitting the payment form details, and using the HTML to display the Continue button, the button which once clicked did display the payments confirmation page.

[kacy-weakley]

Is there any update on this? My team is running into this same issue.

[github-actions[bot]]

No updates yet. Once we get any results, we will post them in this thread.