Option to embed Pact Broker in an iframe (overwrite X-Frame-Options)

[astrod0m]

Hello,

I'm trying to embed our instance of Pact Broker in an iframe in an internal website (which centralises code/test infrastructure), and seeing the iframe fail with "pactbroker... refused to connect.", likely due to the X-Frame-Options: SAMEORIGIN response header from Pact Broker.

1. Could someone point me to where that header is set, please? My searches were unsuccessful.
2. Is it possible to allow users to overwrite that header and allow embedding Pact Broker in an iframe? Possibly a new feature.

Thanks!

All response headers from Pact Broker:

HTTP/1.1 200 OK
Vary: Accept
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/html;charset=utf-8
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Pact-Broker-Version: 2.74.1
Content-Security-Policy: base-uri 'self'; default-src 'self'; font-src 'self' data:; frame-ancestors 'self'; frame-src 'self'; img-src 'self' data: img.shields.io; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'
Content-Length: 45934

[bethesque]

Yes, that header is explicitly there to stop you doing exactly what you're doing ;) It's added by the Rack Protection gem here https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/app.rb#L175

There are a couple of options.

• If you are hosting your broker behind a reverse proxy like ngnix, you could overwrite/delete that header in the response. I'll be honest, this is my preferred option because it means I don't have to do any work!
• The underlying Ruby application, as you can see in the link above, has an option to disable Rack protection altogether, however, that would leave the application quite vulnerable, and I do not recommend this. There would also be work to expose that option in the Docker image.
• You could fork the Docker image and wrap a piece of Ruby middleware around the app that removed the X-Frame-Options header. The downside is that you'd be stuck maintaining the image yourself, and you'd have to keep it up to date manually.
• Last option is that we expose a configuration for this single thing in the Ruby application and the Docker image. I'm not super keen on this because my backlog of open source work is massive at the moment, and this is a very niche use case. If you can make option 1 work, or find someone to submit a PR for this, that would be ideal.

[astrod0m]

Thanks for the quick response, Beth! I went with your first suggestion, and that did the trick. Thanks a lot!