You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Christofer Dutz <du...@c-ware.de> on 2006/06/02 09:29:48 UTC

AW: Restrict users to flow

Hmmm … don’t know why my last post didn’t make it into the List … well …
here another try ;)

 

Hi Foss,

 

Just read your question .. 

How about making all Pipelines you want to protect internal pipelines? 

If the user enters the urls manually they will get “page not found”s but if
Flowscript uses a sendPage it will be shown. 

I use this technique to protect my pipelines from power-user manipulation.

 

Regargs, 

    Christofer Dutz

 

[ c h r i s t o f e r   d u t z ]

 

IT-Berater

univativ GmbH & Co. KG

Robert-Bosch-Str. 7, 64293 Darmstadt

 

fon: 0 61 51 / 66 717 - 21

fax: 0 61 51 / 66 717 - 29

email: christofer.dutz@univativ.de

http://www.univativ.de

 

Darmstadt, Stuttgart, Karlsruhe, Düsseldorf

 

  _____  

Von: Seth Foss [mailto:seth.foss@lat-inc.net] 
Gesendet: Mittwoch, 31. Mai 2006 14:28
An: users@cocoon.apache.org
Betreff: RE: Restrict users to flow

 

Tony,

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

 

Seth

 

  _____  

From: tedwards [mailto:tedwards@civica.com.au] 
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:
    <menu_category type="non-visible">
        <menu label="non-visible">
            <menu-item href="processLinks.do" label="processLinks"
roleName="Public" role="1"/>
            <menu-item href="noticeEdit.do" label="noticeEdit"
roleName="Public" role="1"/>
            <menu-item href="searchHrcy.do" label="searchHrcy"
roleName="Admin" role="256"/>
            <menu-item href="getChildNodesOnly.do" label="getChildNodesOnly"
roleName="Public" role="1"/>
       </menu>
    </menu_category>

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: 

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.

 

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.