[MGNLPN-621] p13n not working with external SPA Created: 15/Feb/22  Updated: 05/Apr/22  Resolved: 24/Feb/22

Status: Closed
Project: Magnolia Personalization
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Bartosz Staryga Assignee: Rishab Dhar
Resolution: Workaround exists Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File Screenshot 2022-02-15 at 15.11.22.png    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:
Epic Link: External SPA Backlog
Sprint: DevX 4
Story Points: 8
Team: DeveloperX

 Description   

Problem

On external SPA on a different domain then Magnolia - In the page editor, on a component when you use the variant selector, it always flips back to "Original". This makes the feature hard to use because an author cannot see the content they are entering! (With that selector)

Notes

p13n with external SPA uses session cookies when fetching template annotations to return the correct selected variant.
The fetch call is a CORS call, and CORS calls by default do not add credentials (e.g. cookies).
It should be achievable with:

  • setting a flag in fetch `credentials: 'include'`
  • setting in cors supportsCredentials
  • not using a wildcard in the allowed origins header

It does work for localhost scenario:

  • magnolia on localhost:8080
  • spa on localhost:3000

or according to this info it might work "for the same second-level domain".

when the same code is run with two different domains/ips

  • magnolia on 192.168.10.10:8080 or magnolia.pl
  • spa on 192.168.10.20:300 or spa.pl
    this is not working.

It looks like browsers are pushing the CORS credentials more than we can find in the available literature.

Browser behaviours affect us that CORS requests for 2 different domains will not pass any credentials regardless of the flags and CORS server settings.

Proposed solution
Move the info/state data to search query params added to the iframe preview.
We already do this:
`?mgnlPreview=false&mgnlChannel=desktop`

We could extend it with:
`?mgnlPreview=false&mgnlChannel=desktop&variants=all&JSESSIONID=5E2232677BE5408B79E90F0BAF591991`

(I am sneaking in `variants=all` here as well )

Then front end code would have to only pass the query params coming from the initial request.
It would also allow the template annotations to be fetched on the server side.

If passing straight session seems to be too bold then we could also add comps id's (hashed to make the ID shorter) and its selected variants. e.g.
`mgnlPreview=false&mgnlChannel=desktop&variants=all&B806B2FC=variant-0&C808B2BG=variant-1`
allowing template annotations to return correct selected variants.



 Comments   
Comment by Rishab Dhar [ 24/Feb/22 ]

This issue is already resolved as a consequence of MGNLPN-606 and PAGES-500.

Regarding the template-annotation request sent by magnolia and the selectedVariant always returning 0 - first the selected variant state is stored internally, and then a template annotation call is made, and then the frontend-helpers project rewrites the value from the internal state storing the selected variant. So this is expected.

In order to test the fix, make sure that the latest version of personalization-rest module is included in the dx-core reactor.

Generated at Mon Feb 12 06:39:27 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.