Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Message-ID: <3FD5EF19.40704@upaya.co.uk>
Date: Tue, 09 Dec 2003 15:49:45 +0000
From: Upayavira <uv@upaya.co.uk>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Authentication and Autorization
References: <1070982490.1493.144.camel@ego.elis.org>
In-Reply-To: <1070982490.1493.144.camel@ego.elis.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Gianluca Sartori wrote:

>Hi all,
>
>	I'm adapting an authentication/authorization system we are using within
>normal JSP/servet pages. It consists of a simple class which must be
>instantiated at the beginning of the page. It knows where to redirect
>the user for authentication and within the JSP/Servlet you can use its
>methods to get user information such as the username, fullname,
>telephone, etc.
>
>What's the best place to incapsulate the funcionalities provided by this
>class? I'm buiding an action for authentication purposes and I plan to
>develop a logicsheet to incapsulate authorization primitives so I can
>declaratively decide whether to make available some data or not
>depending on the current user role.
>
>Is this the way to go? I thought about incapsulate my class into an
>action, but this way I don't know how to take authorization decisions.
>For example I need one "edit" link if the user has the "Editors" role,
>but none if s/he has the "User" role. I don't want to create two
>different pages for this.
>
>Any help?
>
>Thanks,
>Gianluca
>
>  
>
I've just done the same thing, and I used a combination of flow, Woody 
and JXTemplate to achieve it. I found it delightful to use.

If your component is just straight Java, then you can probably use it 
unmodified from Flow, and on the basis of its decisions decide which 
pages to show to users.

Regards, Upayavira


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org