Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Platform fails to start if defining a message origin for an application that provides activators #197

Closed
danielwiehl opened this issue Nov 14, 2022 · 0 comments
Closed

Platform fails to start if defining a message origin for an application that provides activators #197

danielwiehl opened this issue Nov 14, 2022 · 0 comments
Labels
bug
Projects
SCION
Milestone
v1.0.0

Comments

@danielwiehl
Copy link
Collaborator

Describe the bug

The message origin defines where a message from an application must originate to be accepted and delivered by the host. Specifying a different origin may be necessary, for example, if integrating microfrontends into a rich client. The rich client then intercepts messages from applications and "forwards" them to the (remote) host. Thus, such messages originate from the host rather than the application.

However, since activator microfrontends are embedded directly in the host and communication between the host and activator is not bridged, they still originate from the application and not the host, and thus will be rejected by the host.

Expected behavior

Messages from and to activators are not rejected.

Environment

Please complete the following information:

SCION Microfrontend Platform version: 1.0.0-rc.3
@danielwiehl danielwiehl added this to the v1.0.0 milestone Nov 14, 2022
@danielwiehl danielwiehl added this to Triage in SCION via automation Nov 14, 2022
@danielwiehl danielwiehl moved this from Triage to Backlog Microfrontend Platform in SCION Nov 14, 2022
danielwiehl added a commit that referenced this issue Nov 23, 2022
@danielwiehl
fix(platform/host): use secondary origin in addition to application o…
e47014e 
…rigin as allowed origins

Previously, configuring a secondary origin replaced the application's origin as allowed origin.
This was not correct. Instead, the secondary origin should be an additional allowed origin.

This feature was introduced for integrating microfrontends into a rich client to bridge messages
between clients and host across browser boundaries. However, by replacing the origin, activators
could no longer connect to the host.

closes #197

BREAKING CHANGE: Property for configuring a custom message origin has been renamed from `messageOrigin` to `secondaryOrigin`. This breaking change only refers to the host.

To migrate, configure the additional allowed origin via the `secondaryOrigin` property instead of `messageOrigin`, as following:

```ts
await MicrofrontendPlatform.startHost({
  applications: [
    {symbolicName: 'client', manifestUrl: 'https://app/manifest.json', secondaryOrigin: 'https://secondary'},
  ],
});
```
danielwiehl added a commit that referenced this issue Nov 23, 2022
@danielwiehl
fix(platform/host): use secondary origin in addition to application o…
c48be54 
…rigin as allowed origins

Previously, configuring a secondary origin replaced the application's origin as allowed origin.
This was not correct. Instead, the secondary origin should be an additional allowed origin.

This feature was introduced for integrating microfrontends into a rich client to bridge messages
between clients and host across browser boundaries. However, by replacing the origin, activators
could no longer connect to the host.

closes #197

BREAKING CHANGE: Property for configuring a custom message origin has been renamed from `messageOrigin` to `secondaryOrigin`. This breaking change only refers to the host.

To migrate, configure the additional allowed origin via the `secondaryOrigin` property instead of `messageOrigin`, as following:

```ts
await MicrofrontendPlatform.startHost({
  applications: [
    {symbolicName: 'client', manifestUrl: 'https://app/manifest.json', secondaryOrigin: 'https://secondary'},
  ],
});
```
@danielwiehl danielwiehl mentioned this issue Nov 23, 2022
Merged
17 tasks
danielwiehl added a commit that referenced this issue Nov 23, 2022
@danielwiehl
fix(platform/host): use secondary origin in addition to application o…
a0994d2 
…rigin as allowed origins

Previously, configuring a secondary origin replaced the application's origin as allowed origin.
This was not correct. Instead, the secondary origin should be an additionally allowed origin.

This feature was introduced for integrating microfrontends into a rich client to bridge messages
between clients and host across browser boundaries. However, by replacing the origin, activators
could no longer connect to the host.

closes #197

BREAKING CHANGE: Property for configuring a custom message origin has been renamed from `messageOrigin` to `secondaryOrigin`. This breaking change only refers to the host.

To migrate, configure the additional allowed origin via the `secondaryOrigin` property instead of `messageOrigin`, as following:

```ts
await MicrofrontendPlatform.startHost({
  applications: [
    {symbolicName: 'client', manifestUrl: 'https://app/manifest.json', secondaryOrigin: 'https://secondary'},
  ],
});
```
@danielwiehl danielwiehl moved this from Backlog Microfrontend Platform to In Progress in SCION Nov 23, 2022
danielwiehl added a commit that referenced this issue Nov 24, 2022
@danielwiehl
fix(platform/host): add secondary origin to the allowed origins
060565d 
Previously, configuring a secondary origin replaced the application's origin as allowed origin. This was not correct. Instead, the secondary origin should be an additionally allowed origin.

This feature was introduced for integrating microfrontends into a rich client to bridge messages between clients and host across browser boundaries. However, by replacing the origin, activators could no longer connect to the host.

closes #197

BREAKING CHANGE: Property for configuring a secondary origin has been renamed from `messageOrigin` to `secondaryOrigin`. This breaking change only refers to the host.

To migrate, configure the additional allowed origin via the `secondaryOrigin` property instead of `messageOrigin`, as following:

```ts
await MicrofrontendPlatform.startHost({
  applications: [
    {symbolicName: 'client', manifestUrl: 'https://app/manifest.json', secondaryOrigin: 'https://secondary'},
  ],
});
```
danielwiehl added a commit that referenced this issue Nov 24, 2022
@danielwiehl
fix(platform/host): add secondary origin to allowed origins
6044419 
Previously, configuring a secondary origin replaced the application's origin as allowed origin. This was not correct. Instead, the secondary origin should be an additionally allowed origin.

This feature was introduced for integrating microfrontends into a rich client to bridge messages between clients and host across browser boundaries. However, by replacing the origin, activators could no longer connect to the host.

closes #197

BREAKING CHANGE: Property for configuring a secondary origin has been renamed from `messageOrigin` to `secondaryOrigin`. This breaking change only refers to the host.

To migrate, configure the additional allowed origin via the `secondaryOrigin` property instead of `messageOrigin`, as following:

```ts
await MicrofrontendPlatform.startHost({
  applications: [
    {symbolicName: 'client', manifestUrl: 'https://app/manifest.json', secondaryOrigin: 'https://secondary'},
  ],
});
```
danielwiehl added a commit that referenced this issue Nov 24, 2022
@danielwiehl
fix(platform/host): add secondary origin to allowed origins
1252d1d 
Previously, configuring a secondary origin replaced the application's origin as allowed origin. This was not correct. Instead, the secondary origin should be an additionally allowed origin.

This feature was introduced for integrating microfrontends into a rich client to bridge messages between clients and host across browser boundaries. However, by replacing the origin, activators could no longer connect to the host.

closes #197

BREAKING CHANGE: Property for configuring a secondary origin has been renamed from `messageOrigin` to `secondaryOrigin`. This breaking change only refers to the host.

To migrate, configure the additional allowed origin via the `secondaryOrigin` property instead of `messageOrigin`, as following:

```ts
await MicrofrontendPlatform.startHost({
  applications: [
    {symbolicName: 'client', manifestUrl: 'https://app/manifest.json', secondaryOrigin: 'https://secondary'},
  ],
});
```
SCION automation moved this from In Progress to Done Nov 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
SCION
  
Done
Milestone
v1.0.0
Development

No branches or pull requests
1 participant
@danielwiehl