Return-Path: 
 <cocoon-dev-return-22424-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 32276 invoked by uid 500); 7 Feb 2002 17:43:30 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 32265 invoked from network); 7 Feb 2002 17:43:30 -0000
Message-ID: <3C62BC97.9070204@anyware-tech.com>
Date: Thu, 07 Feb 2002 18:42:47 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.8) Gecko/20020204
X-Accept-Language: fr,en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Access Control (was  [RT] Cocoon as OS)
References: <010f01c1afdd$0db937c0$90a4558b@vgritsenkopc>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Vadim Gritsenko wrote:

<snip/>

>>>The main problem, I think, is that HTTP requests on their own do not
>>>have the concept a user built into it, which is necessary to perform
>>>user-based access control.
>>>
>>They have, see (ftp://ftp.isi.edu/in-notes/rfc2617.txt), for all the
>>technical details ;). But it depends on that the browser takes care of
>>the protocol, which leads to: gray box pop-ups.
>>
>
>As you mentioned before: form-based login. IIRC, servlet spec describes
>it in details. Only thing Cocoon needs is may be an action to establish
>user credentials in the servlet container once this form is submitted.
>
<snip/>

But the servlet spec doesn't allow a servlet to set the user credentials 
in the container.

A thing I already though of about request locale : as Cocoon abstracts 
the environment, couldn't we "open" the request interface by adding 
setter methods that allows wrappers to return values set by Cocoon.

To be clear :
in Environment :
  Principal getUserPrincipal();
  setUserPrincipal(Principal user);

in HttpEnvironment :
  Principal userPrincipal = null;

  public void setUserPrincipal(Principal p) {
    this.userPrincipal = p;
  }

  public Principal getUserPrincipal() {
    if (this.userPrincipal == null) {
      return this.userPrincipal;
    } else {
      return this.httpRequest.getUserPrincipal();
    }
  }

This would allow Action-based authenticator to set the User 
transparently to other components. The same could apply to getLocale(), 
which could be overriden by the LocaleAction.

Another way to make these things transparent to other components is to 
replace the request in the object model, but I've been told that 
tweaking the object model is bad ;)

Thoughts ?

Sylvain

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com




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