Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 92 rates

Draft for ?

Streamlining of the Form, Public User Registration and Commenting modules. NEEDS EDIT - some of this stuff has been improved/changed since.

Related concept pages:

Mind map

In a first step we wrote down the problems we are aware of:

Please note that some of those issues have been already addressed, however since it's not possible to edit image easily, this page needs to be rewritten to list problems in more editable form.

--> Form.xmind

Redirecting to a Magnolia-managed login page

To do this, one would typically use RedirectClientCallback.

But RedirectClientCallback can not set the response status to 401 (which could cause problems to non-browser clients, perhaps), since it does a redirect (ie 302).

So it's the job of the login page itself (i.e a magnolia page, ie demo-project/login.html) to set the 401. But there are cases (clicking on a "login" link on the homepage) where this page should be served as a 200.

RedirectClientCallback can substitute a parameter in the target url with the "origin" url. (for example: location: /login.html?origin={0} would cause a redirect to /login.html?origin=/demo-project/protected-page.html) So ideally, login.html uses the "origin" parameter as the "target" of its login form (ultimately taking the user back to where they wanted to go before being hijacked to a login page).

It would probably take a filter to set the error code properly (i.e before rendering), but it should be pretty trivial to do. If we come up with a "standard" name for this parameter, this could be a standard Magnolia filter. ("if parameter mgnlLoginRequestOrigin is in this request, set response status to 401 else leave it be") ... with the exception that we'll need to make sure this status isn't overridden by a 200 later on (rendering filter?)