[MAGNOLIA-1476] allow using a magnolia page as a login page Created: 22/Apr/07  Updated: 23/Jan/13  Resolved: 11/Dec/09

Status: Closed
Project: Magnolia
Component/s: security
Affects Version/s: 3.0.2
Fix Version/s: 3.6.4

Type: Improvement Priority: Major
Reporter: Fabrizio Giustina Assignee: Fabrizio Giustina
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-2485 Provide a HttpClientCallback which do... 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)
Date of First Response:

 Description   

This could be useful for website where magnolia security is used also on the public instance:
at the moment you can only use a static page or a freemarker template for the login page, but not an existing page managed by magnolia. Having a cms-managed login page is a common requirement.

I already have some code for this that I will try to integrate soon, these are a couple of details about how it works:

  • the configuration for the login page doesn't replace the existing one, but it's an additional entry
  • the page is only displayed on public servers and not for the ./magnolia/* path (if the page in the website repository is not configured properly don't prevent administrators to login at all!)
  • the difficult part: when a secure uri is requested, the login page is displayed. After the login the user is redirected to the same page he was trying to see before authentication (with all the parameters submitted originally, and also if he had to navigate across more bages before login for example after a self registration


 Comments   
Comment by Magnolia International [ 31/Jan/08 ]

This might actually be solved (or partially) with the public user registration module.

Comment by Philipp Bärfuss [ 11/Dec/09 ]

This is working: proofed by the new PUR integration into STK

Comment by Magnolia International [ 15/Jan/10 ]

example: one can setup a info.magnolia.cms.security.auth.callback.RedirectClientCallback to redirect to any page for login. Additionally, one could setup a info.magnolia.cms.security.auth.callback.CompositeCallback that will use the regular FormClientCallback for all /.magnolia* stuff and a RedirectClientCallback for anything public/pages.

Comment by Fabrizio Giustina [ 15/Jan/10 ]

mh, I don't think the redirectCallback is enough...
The point here was to keep the address of the requested page, just like the standard login page does. Redirect changes the displayed url and for what I know doesn't automatically redirect the user to the requested page after login, is it?

so the result should be:

Comment by Magnolia International [ 15/Jan/10 ]

It should be fairly straightforward to implement a ForwardingClientCallback instead, but I'm not convinced that's a good solution wrt SEO etc (the same login page could show up with both 200 and 401)

The redirectClientCallback can use url parameters, so all that's left to do is something along the lines of <form action="${request.backto}" ...> in your login page.
Have a look at the javadoc for info.magnolia.cms.security.auth.callback.RedirectClientCallback#setLocation and the source of info.magnolia.cms.security.auth.callback.RedirectClientCallbackTest#testTargetUrlIsFormattedWithEncodedRequestURL

Comment by Fabrizio Giustina [ 15/Jan/10 ]

there is no problem for SEO if it's a protected page and if it's properly returned as a 401 (anyway, it's not worst than indexing a redirect).
I think it's a common use case, so probably a ready-do-use callback you can use without having to worry about form parameters is better... with this solution you also automatically keep parameters in get, which you will have to handle manually in case of redirect.

Anyway, I already implemented a ForwardCallback in the past, do you think it's good to have it in the list of available callback in Magnolia? I can clean it up and commit, or I can keep it in some utility module...

Comment by Magnolia International [ 15/Jan/10 ]

Sure, I don't see why not; specific jira issue

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