[PAGES-500] Component always shows original - even if you select a different variant. Handling component variant selection states on client side Created: 09/Sep/21  Updated: 11/Nov/21  Resolved: 04/Nov/21

Status: Closed
Project: Magnolia pages module
Component/s: None
Affects Version/s: 6.2.11
Fix Version/s: 6.2.12

Type: Bug Priority: Neutral
Reporter: Lam Nguyen Bao Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: VN-Analysis
Remaining Estimate: 0d
Time Spent: 5h
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLPN-606 Store selected variants in the Varian... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[X]* Doc/release notes changes? Comment present?
[X]* Downstream builds green?
[X]* Solution information and context easily available?
[X]* Tests
[X]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[X]* Steps to reproduce, expected, and actual results filled
[X]* Affected version filled
Date of First Response:
Epic Link: External SPA
Sprint: HL & LD 39, HL & LD 40, HL & LD 41
Story Points: 8

 Description   

Currently variant states be synchronized w/ server-side via cookie, sent along w/ the template-annotations/definitions request. Will not work with separate origins & third-party cookies ban

  • Start managing page-editor state on the client side (SPA/standalone page-editor), e.g. like scroll position
  • intercept variant selection event before we communicate to the outer frame via postmessage?

If keeping state using browser's sessionStorage, selection is lost when browser tab is closed. This is expected and acceptable. Alternatively localStorage may be more persistent.



 Comments   
Comment by Christopher Zimmermann [ 09/Sep/21 ]

So what is the exact behviour currently when cookies dont work? Does the personalization UI work at all? or which parts are working and which are not working? This would be useful for determining prioritization of this effort vs other efforts.

Comment by Christopher Zimmermann [ 09/Sep/21 ]

I'm a little concerned aabout the effort and maintenance required for this approach.  As far as I understand it is duplicating/re-implementation logic that is already present on the server. Will this be harder to maintain, ie will any changes or fixes made in one location need to be reimplemented in the other location? Also how will this impact other current features (our own, or customer features) that interact with the editor bars such as "live copy" or maybe in the future "abn testing".

What about handling session in a "cookie-less" future in a different way? Can't session ID  be shared via a querystring or header? Maybe this is a terrrible idea with other negative consequences, but am curious if it might be an option.

Comment by Lam Nguyen Bao [ 13/Sep/21 ]
  •  Functionalities of variant component are working normal using cookies. But it will not work with separate origins & third-party cookies ban. Passing of Sessions with SPA
  • The implementation for storing variant selection on client side should be very simple. Actually, I haven't have change to take a look on other functionalities, to see how it's affected. Ideal case (must be), those functionalities has different responsibilities and must not be affected (separate implementations for additional functionalities).
  • handling session in a "cookie-less" future in a different way? -> We think about simple cases, which already implementation on external page project. BTW, any change in JSESSIONID may cause security issues:
    • HttpOnly protects JSESSIONID from  cross-site scripting. There's no way to get cookie to handle in client side once HttpOnly is enabled (request cookie with headers or URL rewrite are not possible).
Comment by Christopher Zimmermann [ 16/Sep/21 ]

OK, thanks for your input. Fine for me to implement on client. Could we eventually in the future get rid of the "old way" also for non-spa projects. Again I'm hoping to not haave to support multiple implementations. 

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