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

Reply via email to