Flux ArtReceiving a message is not receiving a trusted review result
After generating images with Flux Art, a custom workspace may open a separate preview window where the user selects a version to return. A message event reaching the browser does not prove that the result came from the expected window. Verify the sender first, then the message structure and current operation, and only then update the interface. This article discusses communication between custom pages, not a built-in platform reply protocol. The example fields are defined by the application, not by an OpenAPI response.
Specify which two pages may communicate
Register the complete origins of the parent and preview pages, including scheme, host and effective port. Record which opening action establishes the window relationship. Do not merely test whether a hostname string contains the brand name, or combine addresses from several environments into one allowed value. Configure development, testing and production separately. A window-object identity and an allowed origin answer different questions: one origin can contain several pages, and a reference to the same window does not guarantee that it remains at its original address.
Verify the source before interpreting the business data
MDN's Window.postMessage guidance recommends checking the event's origin, checking source when appropriate, and validating the format of the received data. Senders should specify an explicit target origin. See https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage . The following is a hypothetical message acceptance table, not an actual attack or compatibility test. Until validation is complete, the receiver should leave the current selection unchanged rather than displaying fields from a rejected message and checking them afterward.
| Check | Passing condition | On failure |
|---|---|---|
| Origin | Exact match with a configured origin | Reject the business action |
| Window | Belongs to this preview relationship | Keep the existing selection |
| Structure | Types and version follow the protocol | Record a format error |
| Asset | Within the current authorized set | Reject unknown identifiers |
| Operation | Still awaiting confirmation | Ignore completed operations |
| Duplicate | An existing result is not executed again | Retain the first result |
Allow only the actions defined by the message schema
Define a small, explicit protocol containing a message category, protocol version, operation identifier and permitted asset-version identifier. Validate field types, lengths, required fields and allowed values. Reject unknown actions; do not execute incoming strings as code, DOM fragments or arbitrary navigation instructions. When a message contains an asset identifier, verify it against the set accessible to the current user. A valid origin does not give the sending page permission to request every action the parent can perform.
Recheck the relationship after window navigation
A user may navigate the preview window elsewhere or close it and start another preview. One valid message from an old window is not permanent authentication. Check the origin and window relationship on every message, and correlate the identifier created for this opening with the current pending operation. Completed operations should not accept a second submission. Record duplicate messages as duplicates rather than triggering another save, overwrite or API call. The operation identifier is not a secret password that replaces identity checks.
Restrict the recipient when sending, too
The sender should specify the expected receiving page's origin instead of using an asterisk simply to make delivery easier. Send only the identifiers needed for the current task. Do not place image access tokens, complete keys or unpublished notes in broadcast-style messages. If the receiving window has navigated to another origin, a failed send or missing response should remain incomplete until the user restarts the flow. Do not loosen origins to resolve a timeout, and do not record an unacknowledged message as a successful save by the other page.
Prepare harmless exercises for rejection paths
Suppose the test preview returns a selected version while another test window sends the same message format but is not the registered window. This is a hypothetical scenario, not a real incident. Only a valid message from the expected window should complete the current operation. Also test an incorrect protocol version, an unknown asset identifier, missing fields, a canceled operation and repeated replies. None should change review state. Use dedicated test data; do not send real assets or credentials to uncontrolled third-party pages.
Log the rejection reason without copying all the data
Record the validation stage, a short reason category, the application version and sanitized operation correlation. Do not save full message bodies or entire signed URLs by default. No message received and a message received but rejected are distinct states and should be counted separately during diagnosis. If a legitimate browser environment cannot support the intended flow, provide an ordinary selection-and-confirmation alternative and leave unknown environments pending evidence. Regression records should also cover when listeners are removed, so several old listeners do not process a new message.
Hand over the protocol on both sides and its regression evidence
Include allowed-origin configuration, window creation, message structure, authorization checks, cancellation and duplicate rules, and handling for incompatible protocol versions. The technical basis was checked on November 10, 2026. These protocol and test steps are editorial recommendations, not tests performed on the reader's system. Start creating with Flux Art at https://flux-art.net/en or see https://flux-art.net/en/openapi for server-side integration. Cross-window communication is only one part of a custom workspace; passing it does not establish that file permissions or API authentication are all correct.