[MAGNOLIA-6355] Context object is not exposed to login form in Magnolia 5.4 Created: 24/Aug/15  Updated: 15/Apr/16  Resolved: 21/Oct/15

Status: Closed
Project: Magnolia
Component/s: resource-loader
Affects Version/s: 5.4.1
Fix Version/s: 5.4.3

Type: Bug Priority: Neutral
Reporter: Edgar Vonk Assignee: Evzen Fochr
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: 0d
Time Spent: 1d 4.5h
Original Estimate: Not Specified

Issue Links:
documentation
relation
is related to MGNLRES-149 Concept for supporting processing res... Closed
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:
Sprint: Kromeriz 15
Story Points: 2

 Description   

I don't know exactly how to describe it but as reported in SUPPORT-5028 Magnolia 5.4.1 is not backwards compatible with regards to our custom (FTL-based) login pages which we load as resources.

We have the following use case which we use in Magnolia 5.3 (and earlier) but which no longer works in 5.4.1:

Situation in 5.3:

  • we have a custom login page in our custom module located in: /src/main/resources/mgnl-resources/custom-website/custom-login-form/custom-login-form.ftl. this login page contains Freemarker Magnolia logic such as:
     [#if ctx.user.name == 'anonymous']
  • we have configured our website to use this login form (when a user attempts to access secure content) in the securityCallbackFilter: /mgnl-resources/custom-website/custom-login-form/custom-login-form.ftl

Because of this issue we cannot migrate our projects to Magnolia 5.4 at this stage (without losing functionality).



 Comments   
Comment by Edgar Vonk [ 26/Aug/15 ]

I am not sure if MGNLRES-149 covers this issue completely but it might do. If so you may close this issue as a duplicate.

Comment by Magnolia International [ 10/Sep/15 ]

This has very little to do with resources or processed resources, but is indeed a regression in 5.4

SecurityCallbackFilter uses ClientCallback, which (for FormClientCallback) then uses SimpleFreemarkerHelper, which is indeed new in 5.4 (MAGNOLIA-6253), and was created because SecurityCallbackFilter could not be split out of core at the time.

To fix Edgar's issue, as per the Javadoc of SimpleFreemarkerHelper, we should re-add ctx to the template context in FormClientCallback#getTemplateContext. Edgar, do you also use state, which is AggregationState ? IIRC it won't be "complete" yet when rendering a login form; what do you use it for ?

Comment by Magnolia International [ 10/Sep/15 ]

When further confirming this, let's change the title to "[...] exposed to login form", because they are, for other freemarker templates (which is what this is about). I'm realizing "processed resources" as they were implemented, are causing some confusion in terminology: they were in effect passed through freemarker as if they were a template.

Comment by Edgar Vonk [ 10/Sep/15 ]

Hi @gjoseph,

Thanks for clearing it up.

No we just use the ctx object.

See SUPPORT-5028 on how we use it.

cheers

Comment by Edgar Vonk [ 16/Sep/15 ]

Hi. Any updates on this issue maybe? And is there a simple workaround in the meantime maybe? We really need this functionality back..

Generated at Mon Feb 12 04:13:44 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.