Feature 2: Ambits (for request and postbacks)

[Alarc�n Vladimir <vl...@yahoo.com>]

Hi! This is the second feature I was thinking on
including in Shale. Perhaps this could reduce the
silly code for session checking and logged in users.

When a user make a request/postback to a web
application I can distinguish between 3 different
situations: an unrelated (complete new) request, or a
request that can be related with a previous one with a
session. The second case can be divided again in two:
a request marked as "authenticated" and a request
markes as "non autheticated". I would like to treat
these cases as "ambits" (please change the name if
appropiated) because for me they have different
implications.

1) UNBOUND ambit: The web application can not relate
this request/postback with any previous request. It's
coming from "outer space". No HttpSession is found or
one is found but it's a new one, created by the
container or other. Usually this happens when the
browser accesses the first page of the application or
when the session has expired.

2) BOUND ambit: The web application can relate this
request/postback with a previous one (a valid session
was found) and it's not marked as authenticated. Every
request/postback in UNBOUND ambit should be changed to
BOUND ambit by Shale, with session creation if needed.

3) AUTHENTICATED ambit: The web application can relate
this request/postback with a previous one (a valid
session was found) and it's marked as authenticated.

Any application could work in any of these three
ambits, although with Shale typically we would like to
stay on the last two. Usually we will provide views in
an UNBOUND and BOUND ambits as means to arrive to
AUTHENTICATED areas where everything interesting
happens. As a counterexample, we could speak of a web
site such as www.amazon.com where you typically spend
a lot of time in an BOUND ambit (to search and look
around), and only a few times we decide to enter the
AUTHENTICATED area (to buy something).

I think it would be useful to be able to indicate to
Shale which pages should be accessed in wich ambits.
For example, there are pages that only authenticated
user should access. If thw browser receives a
request/postback in a non-allowed ambit some method of
the backing bean should be called to decide what to do
(perhaps the session has expired and we need to
redirect the user to a login page).

The eight combinations for each page that I can see
are:
    ALLOW_NONE: this page cannot be accessed from any
ambit. Perhaps this should be the default value to
force a definition by the user.
    ALLOW_UNBOUND: only unbound requests can access
this page.
    ALLOW_BOUND: only bound requests can access this
page.
    ALLOW_UNBOUND_BOUND: only unbound and bound
requests can access this page.
    ALLOW_AUTHENTICATED: only authenticated requests
can access this page.
    ALLOW_UNBOUND_AUTHENTICATED: only unbound and
authenticated requests can access this page.
    ALLOW_BOUND_AUTHENTICATED: only bound and
authenticated requests can access this page.
    ALLOW_ALL: all request can access this page

The change from UNBOUND to BOUND should be
automatically made by Shale. The change to/from
authenticated should requiere an explicit action from
the backing bean, such as calling some methods:
    registerAuthentication(): to change to
AUTHENTICATED ambit.
    invalidateAuthentication(): to change to BOUND
ambit.
    invalidateSessionAndRebind(): to invalidate the
session and change to BOUND ambit.

The definition of the ambit for each page could be
made in a declarative (configuration file) or
programatique (methods of the backing bean) way. 

The methods called when an invalid ambit is found
could be declared in each backing bean or inherited
from one or more superclasses of them.

That's it.

PS: Sorry for my english.




 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re: Feature 2: Ambits (for request and postbacks)

[Craig McClanahan <cr...@apache.org>]

On 11/23/06, Alarcón Vladimir <vl...@yahoo.com> wrote:
>
> Hi! This is the second feature I was thinking on
> including in Shale. Perhaps this could reduce the
> silly code for session checking and logged in users.
>
> When a user make a request/postback to a web
> application I can distinguish between 3 different
> situations: an unrelated (complete new) request, or a
> request that can be related with a previous one with a
> session. The second case can be divided again in two:
> a request marked as "authenticated" and a request
> markes as "non autheticated". I would like to treat
> these cases as "ambits" (please change the name if
> appropiated) because for me they have different
> implications.
>
> 1) UNBOUND ambit: The web application can not relate
> this request/postback with any previous request. It's
> coming from "outer space". No HttpSession is found or
> one is found but it's a new one, created by the
> container or other. Usually this happens when the
> browser accesses the first page of the application or
> when the session has expired.
>
> 2) BOUND ambit: The web application can relate this
> request/postback with a previous one (a valid session
> was found) and it's not marked as authenticated. Every
> request/postback in UNBOUND ambit should be changed to
> BOUND ambit by Shale, with session creation if needed.
>
> 3) AUTHENTICATED ambit: The web application can relate
> this request/postback with a previous one (a valid
> session was found) and it's marked as authenticated.
>
> Any application could work in any of these three
> ambits, although with Shale typically we would like to
> stay on the last two. Usually we will provide views in
> an UNBOUND and BOUND ambits as means to arrive to
> AUTHENTICATED areas where everything interesting
> happens. As a counterexample, we could speak of a web
> site such as www.amazon.com where you typically spend
> a lot of time in an BOUND ambit (to search and look
> around), and only a few times we decide to enter the
> AUTHENTICATED area (to buy something).
>
> I think it would be useful to be able to indicate to
> Shale which pages should be accessed in wich ambits.
> For example, there are pages that only authenticated
> user should access. If thw browser receives a
> request/postback in a non-allowed ambit some method of
> the backing bean should be called to decide what to do
> (perhaps the session has expired and we need to
> redirect the user to a login page).
>
> The eight combinations for each page that I can see
> are:
>     ALLOW_NONE: this page cannot be accessed from any
> ambit. Perhaps this should be the default value to
> force a definition by the user.
>     ALLOW_UNBOUND: only unbound requests can access
> this page.
>     ALLOW_BOUND: only bound requests can access this
> page.
>     ALLOW_UNBOUND_BOUND: only unbound and bound
> requests can access this page.
>     ALLOW_AUTHENTICATED: only authenticated requests
> can access this page.
>     ALLOW_UNBOUND_AUTHENTICATED: only unbound and
> authenticated requests can access this page.
>     ALLOW_BOUND_AUTHENTICATED: only bound and
> authenticated requests can access this page.
>     ALLOW_ALL: all request can access this page
>
> The change from UNBOUND to BOUND should be
> automatically made by Shale. The change to/from
> authenticated should requiere an explicit action from
> the backing bean, such as calling some methods:
>     registerAuthentication(): to change to
> AUTHENTICATED ambit.
>     invalidateAuthentication(): to change to BOUND
> ambit.
>     invalidateSessionAndRebind(): to invalidate the
> session and change to BOUND ambit.
>
> The definition of the ambit for each page could be
> made in a declarative (configuration file) or
> programatique (methods of the backing bean) way.
>
> The methods called when an invalid ambit is found
> could be declared in each backing bean or inherited
> from one or more superclasses of them.


As with the previous proposal, this kind of thing should really be discussed
on the developer list.

Regarding this particular proposal, one of the interesting questions in
framework design is "when do I stop"?  In other words, do you perceive that
you need to solve all of the worlds problems, or can I interoperate with
other frameworks that address different aspects of the overall application
architecture.

With regards to authentication and authorization, the "gold standard" that
you have to start with is container managed security, as defined in the
servlet specification.  What is interesting is that nearly all the popular
approaches to this problem space tend to be API compatible with container
managed security (for example, you can call request.getRemoteUser() and
request.isUserInRole() to make security related decisions).  So, the
fundamental issue for Shale is, is there anything needed to be done that is
not covered by such existing frameworks?  Or, put another way, why should we
add it to Shale instead of just using an existing security related
framework?

There *are* some things that container managed security (and systems that
emulate it, like Acegi and securityfilter) don't do, but they *do* cover the
cases you talk about above.  What is it that makes these things that Shale
should provide specific support for on its own?

Craig


That's it.
>
> PS: Sorry for my english.
>
>
>
>
>
>
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
>