Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

{rate} {status:implemented|
Devstatus
Wiki Markup
Statusimplemented
Target
4.5
}

Simplifies

configuration

of

login

callbacks

and

allows

simpler

WebDAV

and

RSS

support.

See

[

MAGNOLIA-3858@jira

]

and

[

MAGNOLIA-3863@jira

].{status} h1. Rationale Currently, one can configure multiple login callbacks by using {{CompositeCallback}}. With a fairly complex configuration, this allows to configure different callbacks based on the requested urls (typically {{/.magnolia}} will be protected by the regular Magnolia login form, while a protected but public section of a website will redirect a login form from the website itself). On top of the complex configuration, there are at least two drawbacks to the current configuration: * One can only select a different callback based on a url pattern. * Depending on which filter is hit, the patterns are different, especially in multi-site configurations (because UrlPatternDelegate#match uses {{AggregationState.getCurrentURI()}}, which returns a value that can change depending on where the filter is in the chain. h1. Current workarounds The WebDav module's {{WebdavAwareUriSecurityFilter}} uses 2 techniques to work around this: it checks the existence of a WebDav-specific request header, and uses a pattern matching against the user-agent: if either condition is true, it forces the usage of a {{BasicClientCallback}} ({{

.

Officialdocu
0Filters > Security Callback
1http://wiki.magnolia-cms.com/display/DOCS45/Filters#Filters-SecurityCallback

Rationale

Currently, one can configure multiple login callbacks by using CompositeCallback. With a fairly complex configuration, this allows to configure different callbacks based on the requested urls (typically /.magnolia will be protected by the regular Magnolia login form, while a protected but public section of a website will redirect a login form from the website itself).

On top of the complex configuration, there are at least two drawbacks to the current configuration:

  • One can only select a different callback based on a url pattern.
  • Depending on which filter is hit, the patterns are different, especially in multi-site configurations (because UrlPatternDelegate#match uses AggregationState.getCurrentURI(), which returns a value that can change depending on where the filter is in the chain.

Current workarounds

The WebDav module's WebdavAwareUriSecurityFilter uses 2 techniques to work around this: it checks the existence of a WebDav-specific request header, and uses a pattern matching against the user-agent: if either condition is true, it forces the usage of a BasicClientCallback (response.setHeader("WWW-Authenticate"...

...

),

...

otherwise

...

it

...

uses

...

the

...

regular

...

mechanism.

...

Existing

...

problems

...

Authenticated

...

feeds

...

for

...

RSS

...

are

...

also

...

a

...

problem

...

(

...

MGNLRSSAGG-31@jira

...

),

...

because

...

you

...

can't

...

expect

...

users

...

to

...

manually

...

subscribe

...

to

...

a

...

feed

...

by

...

adding

...

their

...

credentials

...

in

...

the

...

url.

...

It

...

seems

...

most

...

clients

...

respond

...

fairly

...

well

...

to

...

a

...

Basic

...

auth,

...

though.

...

Proposed

...

solution

...

Add

...

an

...

accepts(HttpServletRequest

...

request)

...

method

...

to

...

HttpClientCallback

...

,

...

and

...

allow

...

configuring

...

a

...

chain

...

of

...

such

...

call

...

backs

...

at

...

security

...

level

...

filter;

...

first

...

call

...

back

...

that

...

accepts

...

the

...

request

...

processes

...

it.

...

The

...

WebDav

...

module

...

could

...

then

...

use

...

the

...

regular

...

security

...

filters,

...

but

...

insert

...

its

...

custom

...

callback

...

early

...

in

...

the

...

chain;

...

same

...

thing

...

for

...

the

...

rss

...

module.

...

(which

...

could

...

"accept"

...

the

...

request

...

based

...

on

...

a

...

list

...

of

...

known

...

user

...

agents,

...

or

...

a

...

url

...

pattern

...

or

...

extension...)

...

I'm

...

also

...

assuming

...

that

...

this

...

would

...

make

...

it

...

simpler

...

to

...

have

...

a

...

multi-site

...

aware

...

callback.

...

Additionally,

...

we're

...

introducing

...

an

...

extra

...

filter

...

to

...

"catch"

...

the

...

401/403

...

status

...

as

...

well

...

as

...

AccessDeniedException}}s;

...

existing

...

subclasses

...

of

...

{{BaseSecurityFilter

...

will

...

not

...

handle

...

the

...

callbacks

...

anymore,

...

but

...

merely

...

set

...

an

...

http

...

status.

...

The

...

new

...

filter

...

will

...

have

...

callbacks

...

configured

...

and

...

handle

...

them.