Use postMessage in embed mode instead of custom events

[LukasHirt]

Description

We have switched to using postMessage method in the embed mode instead of emitting custom events. This mitigates the issue when running the embed mode on different origin blocked the access to the dispatchEvent method.

Motivation and Context

Solve issues with forbidden access when hosting the iframe on different origin.

How Has This Been Tested?

• test environment: local
• test case 1: run the embed mode and check the correct events being emitted

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised:

[dschmidt]

I think the Sonarcloud comments are actually legit. I'm just not sure where we want to retrieve this information from

[LukasHirt]

I think the Sonarcloud comments are actually legit. I'm just not sure where we want to retrieve this information from

@dschmidt I guess we need to introduce new prop in config for that then? Should * still be used as a callback though in case it is not defined?

[dschmidt]

Not sure, on the one hand that's kind of an invitation to not configure it properly... on the other hand if CSP is configured properly it should be rather safe anyhow

[LukasHirt]

Not sure, on the one hand that's kind of an invitation to not configure it properly... on the other hand if CSP is configured properly it should be rather safe anyhow

I still added it. I don't think there is any way we can secure the value ourselves as it will always depend on the deployment. Regarding not configuring it properly, I guess this is a danger we can live with? And even if the CSP would handle it, as long as it is best practice, I would set it anyway 🤷

[dschmidt]

Not sure, on the one hand that's kind of an invitation to not configure it properly... on the other hand if CSP is configured properly it should be rather safe anyhow

I still added it. I don't think there is any way we can secure the value ourselves as it will always depend on the deployment. Regarding not configuring it properly, I guess this is a danger we can live with? And even if the CSP would handle it, as long as it is best practice, I would set it anyway 🤷

My point is: having * as default is a worse than having no default. Obviously people can still set it and then it's not our fault (and in fact I hate hate hate when software tells me I can't use a value because it's unsafe even if I know what I'm doing), but we maybe should not have it as a default if users don't configure anything. I think if someone wants to use embed mode, we can request to set a config value

[JammingBen]

I think if someone wants to use embed mode, we can request to set a config value

I agree since there is no other default value that would make sense.

Maybe we also should move the mode config into the new embed object and rename it to something like enabled? That way all the embed-configs would be together in one place (and I can't really think of another mode to come in the future).

[LukasHirt]

@dschmidt now I get it, there was a bit of a misunderstanding from my side. Default is dropped now and it is configurable.

@JammingBen changelog items updated to include the link and dropping the changes and also the mode prop moved to embed group.

[JammingBen]

Unit tests still fail, code LGTM though 👍

[LukasHirt]

Strange that the E2E tests are failing as it seems unrelated to my changes... I'll try to see what's going on

[JammingBen]

Strange that the E2E tests are failing as it seems unrelated to my changes... I'll try to see what's going on

Could you try rebasing with current master?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

95.5% Coverage
0.0% Duplication