You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Quinton McCombs <qm...@nequalsone.com> on 2002/12/11 22:30:47 UTC

Advice on implementing security

I need to secure some of my screens.  Before allowing the user to access
a particular screen, I will check to make sure that the user has the
appropriate permission.  If they do not, I want to send them to
different screen to display a friendly message about not having the
appropriate security.  I already understand how to change the screen
template in an actions.  The question is how do I do this if I am not
calling an action?

Re: Advice on implementing security

Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:

>------_=_NextPart_001_01C2A15C.91CA58A0
>Content-Type: text/plain;
>	charset="us-ascii"
>Content-Transfer-Encoding: quoted-printable

>I need to secure some of my screens.  Before allowing the user to access
>a particular screen, I will check to make sure that the user has the
>appropriate permission.  If they do not, I want to send them to
>different screen to display a friendly message about not having the
>appropriate security.  I already understand how to change the screen
>template in an actions.  The question is how do I do this if I am not
>calling an action?

By using the great hack called "login.action" :-)

Basically it goes like this:

First request comes in. It is for "Index.vm"
              |
              v 
Turbine checks, whether this request contains the "login" or "logout"
action.
              |  No
              v
Turbine fetches the SessionValidator from the action.sessionvalidator
property. This _should_ be in your case the
sessionvalidator.TemplateSecureSessionValidator

The Sessionvalidator notices, that you don't have logged in yet (that
in fact we don't even have a valid user object). It then displays
the message defined in login.message and fetches the name of the
"log user in" template from template.login property. It then sends
you there.

If the session validator decides, that you are a valid user, it then
returns to Turbine which in turn calls the AccessController, which
then builds your ACL. After that, the "normal" Action -> Screen
sequence starts.

In a nutshell:

properties:

--- cut ---
#
# First Screen displayed after being logged on (valid user)
# This is _NOT_ the first screen to be seen if you're not a 
# valid user. In this case, the SessionValidator sends you to the
# login screen defined below.
template.homepage = Index.vm 

#
# Screen you get sent to by the SessionValidator if you're not
# logged in
template.login = Login.vm

#
# Session Validator which makes sure that you're really authorized
action.sessionvalidator= sessionvalidator.TemplateSecureSessionValidator

#
# Access Controller which builds your ACL after you've logged on and
# got verified by the Session Validator
action.accesscontroller= AccessController

#
# Default Java class which backs your screens. Custom Classes to
# back your screens should extend this so you get protection on all
# screens. 
# If you want non-secured screens, you should define a 
# subtree e.g. "insecure" and put a insecure.Default class there
# which just extends VelocityScreen
#
services.VelocityService.default.screen= VelocitySecureScreen
--- cut ---

Actions should extend the VelocitySecureAction.

Ah, and the action.login and action.logout properties do really have a
meaning. These are special actions that are called _before_ the
SessionValidator and AccessController. This is needed because else
your Login Screen would reference an action to log the user in which
in turn is not called because the SessionValidator would send you back
to the Login Screen before the Action -> Screen cycle really starts.

The Defaults for these are

action.login = LoginUser

and

action.logout = LogoutUser

which are translated to org.apache.turbine.modules.actions.LoginUser/LogoutUser

if you use a custom login action, you should adjust these properties.

So in your case, you put the page where you welcome an authorized User
on Index.vm. The page where you tell an user that he is not authorized
and should log in (including the form to login) on the Login.vm page.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>