Return-Path: Delivered-To: apmail-cocoon-users-archive@www.apache.org Received: (qmail 96674 invoked from network); 31 May 2006 12:27:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 May 2006 12:27:32 -0000 Received: (qmail 84520 invoked by uid 500); 31 May 2006 12:27:25 -0000 Delivered-To: apmail-cocoon-users-archive@cocoon.apache.org Received: (qmail 84375 invoked by uid 500); 31 May 2006 12:27:25 -0000 Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: users@cocoon.apache.org List-Id: Delivered-To: mailing list users@cocoon.apache.org Received: (qmail 84320 invoked by uid 99); 31 May 2006 12:27:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 05:27:24 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [63.252.160.58] (HELO exchange.lat-inc.net) (63.252.160.58) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 05:27:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C684AD.BEED32A4" Subject: RE: Restrict users to flow Date: Wed, 31 May 2006 08:28:27 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Restrict users to flow Thread-Index: AcaEPej41H7+sOZxQPqyeHNF21St4gAb2N4g From: "Seth Foss" To: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C684AD.BEED32A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tony, That looks like just what I need. Could you give me an example of how your are accessing that xml from your sitemap? =20 Seth ________________________________ From: tedwards [mailto:tedwards@civica.com.au]=20 Sent: Tuesday, May 30, 2006 7:06 PM To: users@cocoon.apache.org Subject: Re: Restrict users to flow Hi Seth, I restrict what users can and can't do by running them through a 'traffic cop' of sorts. I have a navigation document which performs 2 functions: 1 is to generate the menus that the program displays and the other is to determine who can have access to a particular portion of the application. For example: A section of my navigation.xml looks like this:

When a user tries to access a particular flow function like 'searchHrcy.do', their user permissions (a global variable obtained at login) is compared to the role attribute of the menu-item. If they don't have sufficient privileges to access this function then they are redirected. Similarly if they attempt to access and function not listed in the navigation.xml, an error is generated and they are redirected. All this role checking and redirection is handled by flow. This could be extended to include any pipeline calls as well by listing them in the navigation document and using flow to call sendPage(menu-item). I hope this makes sense. The application I am writing required really fine grained access level so I knocked up this 'traffic cop' to check every public flow function. If you need more detail, let me know. Regards Tony Seth Foss wrote:=20 How do I restrict a user from accessing pipelines outside of flowscript? I can figure out how to redirect un-authenticated users to a login page, but if logged-in users manually enter a pipeline into the address bar, how do I redirect them into my flowscript. I plan on using continuations, so Submits and Nexts will not direct to the correct pages without the flowscript running. =20 Seth Foss -- This email is from Civica Pty Limited and it, together with any attachments, is confidential to the intended recipient(s) and the contents may be legally privileged or contain proprietary and private information. It is intended solely for the person to whom it is addressed. If you are not an intended recipient, you may not review, copy or distribute this email. If received in error, please notify the sender and delete the message from your system immediately. Any views or opinions expressed in this email and any files transmitted with it are those of the author only and may not necessarily reflect the views of Civica and do not create any legally binding rights or obligations whatsoever. Unless otherwise pre-agreed by exchange of hard copy documents signed by duly authorised representatives, contracts may not be concluded on behalf of Civica by email. Please note that neither Civica nor the sender accepts any responsibility for any viruses and it is your responsibility to scan the email and the attachments (if any). All email received and sent by Civica may be monitored to protect the business interests of Civica.=20 ------_=_NextPart_001_01C684AD.BEED32A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tony,

That looks like just what = I need.=20 Could you give me an example of how your are accessing that xml from = your=20 sitemap?

Seth

From: tedwards = [mailto:tedwards@civica.com.au]=20
Sent: Tuesday, May 30, 2006 7:06 PM
To:=20 users@cocoon.apache.org
Subject: Re: Restrict users to=20 flow

Hi Seth,
I restrict what users can and can't do by running = them=20 through a 'traffic cop' of sorts.
I have a navigation document which = performs=20 2 functions: 1 is to generate the menus that the program displays and = the other=20 is to determine who can have access to a particular portion of the=20 application.

For example:

A section of my navigation.xml = looks=20 like this:
    <menu_category=20 type=3D"non-visible">
        = <menu=20 label=3D"non-visible">
       =20     <menu-item href=3D"processLinks.do" = label=3D"processLinks"=20 roleName=3D"Public" role=3D"1"/>
    =    =20     <menu-item href=3D"noticeEdit.do" = label=3D"noticeEdit"=20 roleName=3D"Public" role=3D"1"/>
    =    =20     <menu-item href=3D"searchHrcy.do" = label=3D"searchHrcy"=20 roleName=3D"Admin" role=3D"256"/>
    =    =20     <menu-item href=3D"getChildNodesOnly.do"=20 label=3D"getChildNodesOnly" roleName=3D"Public"=20 role=3D"1"/>
      =20 </menu>
    </menu_category>

When a = user=20 tries to access a particular flow function like 'searchHrcy.do', their = user=20 permissions (a global variable obtained at login) is compared to the = role=20 attribute of the menu-item. If they don't have sufficient privileges to = access=20 this function then they are redirected.
Similarly if they attempt to = access=20 and function not listed in the navigation.xml, an error is generated and = they=20 are redirected.
All this role checking and redirection is handled by = flow.=20 This could be extended to include any pipeline calls as well by listing = them in=20 the navigation document and using flow to call = sendPage(menu-item).

I=20 hope this makes sense. The application I am writing required really fine = grained=20 access level so I knocked up this 'traffic cop' to check every public = flow=20 function.
If you need more detail, let me=20 know.

Regards
Tony

Seth Foss wrote:=20

How = do I restrict=20 a user from accessing pipelines outside of flowscript? I can figure out how to = redirect=20 un-authenticated users to a login page, but if logged-in users = manually enter=20 a pipeline into the address bar, how do I redirect them into my = flowscript. I=20 plan on using continuations, so Submits and Nexts will not direct to = the=20 correct pages without the flowscript running.

Seth = Foss

--

This email is from Civica Pty Limited and it, together with = any=20 attachments, is confidential to the intended recipient(s) and the = contents may=20 be legally privileged or contain proprietary and private information. It = is=20 intended solely for the person to whom it is addressed. If you are not = an=20 intended recipient, you may not review, copy or distribute this email. = If=20 received in error, please notify the sender and delete the message from = your=20 system immediately. Any views or opinions expressed in this email and = any files=20 transmitted with it are those of the author only and may not necessarily = reflect=20 the views of Civica and do not create any legally binding rights or = obligations=20 whatsoever. Unless otherwise pre-agreed by exchange of hard copy = documents=20 signed by duly authorised representatives, contracts may not be = concluded on=20 behalf of Civica by email. Please note that neither Civica nor the = sender=20 accepts any responsibility for any viruses and it is your responsibility = to scan=20 the email and the attachments (if any). All email received and sent by = Civica=20 may be monitored to protect the business interests of Civica. =

------_=_NextPart_001_01C684AD.BEED32A4--