Details
-
New Feature
-
Status: Resolved
-
Minor
-
Resolution: Won't Fix
-
0.7
-
None
-
None
-
Windows XP
Description
With DocBook, I am able to specify element roles. DocBook profiling XSLs can then be used to produce documents based on say a user profile. This is very valuable if you provide a website to both users and support staff as you can generate a version of the document suitable for each user role profile.
It would be great, if forrest can be extended with user name and password login feature, user to role/group/any-other-profile mapping feature (in effect access control) and profile-based document generation (for both content documents and tabs|site.xmls).
Here is a content use-case:
1. a some-tool.xml DocBook document contains two sections, one applicable to any user (DocBook role attribute = "user;support") and one that is applicable to just support staff (attribute="support").
2. a mapping file should exist that maps say guest and joe.user to user roles, whilst joe.support is mapped to support role.
3. when guest or joe.user want to view some-tool.html or .pdf file, the xml file is profiled and only section 1 is included in the output, whilst when joe.support views the same document, section 1 and 2 are included.
Here is a navigation use-case (using concepts from previos use case):
1. another-tool.xml DocBook document should only be seen by support role staff, so a new attribute is required in sites and tabs.xml files, say role to again provide profiling.
2. so when joe.user views the website, another-tool.html|pdf link is not even presented, but joe.support sees the link.
Here is the original email thread:
-----Original Message-----
From: Ross Gardler [mailto:rgardler@apache.org]
Sent: 21 November 2004 13:49
To: dev@forrest.apache.org
Subject: Re: Dynamic or Static Access Control Lists
Thorsten Scherler wrote:
> El dom, 21-11-2004 a las 09:13, Alex Batlin escribió:
>
>>Has anyone configured Forrest to allow user to provide userid and
>>password, and then generated documents based on their role/group.
>>Document elements can then be tagged with role/group. I am thinking of
>>the way profiling is done in DocCook.
>
>
> No, not AFAIK, but it should be quite easy.
>
> I will need auth as well pretty soon for profiling. You can either beat
> me by sending a patch or hang in there and wait (I guess end of the
> year) till I implemend it.
>
> Basicly you have to do the following for auth, protected docs and
> profiling:
> 1) create a dir where the protected docs go
> 2) create a auth pipeline where you start the session
> 3) add profiling to the session in your profiling
> 4) change your skin pipelines to display the profiled content
>
> Can you open an enhancement issue and add this to it. This way it will not get lost.
There are a number of authorisation blocks in Cocoon. Take a look at the
Cocoon docs and their wiki for examples. If you fancy having a go at
implementing this before it reaches the top of Throsten's ToDo list we
will be happy to advise on the best approach.
Ross
It would be great, if forrest can be extended with user name and password login feature, user to role/group/any-other-profile mapping feature (in effect access control) and profile-based document generation (for both content documents and tabs|site.xmls).
Here is a content use-case:
1. a some-tool.xml DocBook document contains two sections, one applicable to any user (DocBook role attribute = "user;support") and one that is applicable to just support staff (attribute="support").
2. a mapping file should exist that maps say guest and joe.user to user roles, whilst joe.support is mapped to support role.
3. when guest or joe.user want to view some-tool.html or .pdf file, the xml file is profiled and only section 1 is included in the output, whilst when joe.support views the same document, section 1 and 2 are included.
Here is a navigation use-case (using concepts from previos use case):
1. another-tool.xml DocBook document should only be seen by support role staff, so a new attribute is required in sites and tabs.xml files, say role to again provide profiling.
2. so when joe.user views the website, another-tool.html|pdf link is not even presented, but joe.support sees the link.
Here is the original email thread:
-----Original Message-----
From: Ross Gardler [mailto:rgardler@apache.org]
Sent: 21 November 2004 13:49
To: dev@forrest.apache.org
Subject: Re: Dynamic or Static Access Control Lists
Thorsten Scherler wrote:
> El dom, 21-11-2004 a las 09:13, Alex Batlin escribió:
>
>>Has anyone configured Forrest to allow user to provide userid and
>>password, and then generated documents based on their role/group.
>>Document elements can then be tagged with role/group. I am thinking of
>>the way profiling is done in DocCook.
>
>
> No, not AFAIK, but it should be quite easy.
>
> I will need auth as well pretty soon for profiling. You can either beat
> me by sending a patch or hang in there and wait (I guess end of the
> year) till I implemend it.
>
> Basicly you have to do the following for auth, protected docs and
> profiling:
> 1) create a dir where the protected docs go
> 2) create a auth pipeline where you start the session
> 3) add profiling to the session in your profiling
> 4) change your skin pipelines to display the profiled content
>
> Can you open an enhancement issue and add this to it. This way it will not get lost.
There are a number of authorisation blocks in Cocoon. Take a look at the
Cocoon docs and their wiki for examples. If you fancy having a go at
implementing this before it reaches the top of Throsten's ToDo list we
will be happy to advise on the best approach.
Ross