Sorry by question, but what is sunRise-auth action ?
Where this action deploy?

Yury.
 

Carsten Ziegeler wrote:

>Hi Peter,
>
>all your pipelines are wrapped (secured) by the sunRise-auth action
>with the handler and the application parameter, for example the
>sunLets:
>
>      <map:match pattern="sunspotdemo**">
>               <map:act type="sunRise-auth">
>                       <map:parameter name="handler" value="sunspotdemohandler"/> 
>                       <map:parameter name="application" value="sunspotdemo"/> 
>               
>                       <map:match pattern="sunspotdemosunlet-*.xml"> 
>                               <map:generate 
>src="sunspotdemo/resources/auth/sunlet-{1}.xml"/>
>                               <map:serialize type="xml"/>
>                       </map:match>
>            </map:act>
>      </map:match>
>
>The sunRise-auth action provides several key/value pairs that can be used
>inside the sitemap like the ID of the current user, the role etc.
>So your example could look like this:
>
>               <map:act type="sunRise-auth">
>                       <map:parameter name="handler" value="sunspotdemohandler"/> 
>                       <map:parameter name="application" value="sunspotdemo"/> 
>
>                  <map:generate src="application.xml">
>                          <map:parameter name="user_id" value="{ID}"/>
>                   </map:generate>
>                   ....
>
>HTH
>
>Carsten
>
>>-----Original Message-----
>>From: Baer Peter [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, March 19, 2002 1:40 PM
>>To: cocoon-users
>>Subject: Re: RE: How to put user data into SunspotDemoPortal-session at
>>logon time
>>
>>
>>Thanks for the reply. It works. We can get the parameter out of the 
>>session now.
>>
>>However, what we actually need is a single value which we can pass as a 
>>parameter to the following generator or transformer.
>>
>><map:generate src="application.xml">
>>      <map:parameter name="user_id" value="{session/user/name}"/>
>></map:generate>
>>
>>Thus we could generate user-specific menus at runtime. Eg, the options 
>>in drop-down menu could depend on the region the user belongs to.
>>
>>Merging the session XML and the application XML is not appropriate for 
>>us, as we don't want to have them transformed before the XSP statements 
>>in the resulting XML are evaluated.
>>
>>Any clues?
>>
>>Thanks in advance!
>>
>>      -pb-
>>
>>
>>
>>
>> >Everything is already in the session, stored in a so called 
>> >SessionContext
>> >named "sunRise".
>> >
>> >The "authentication document" defined for the portal which actually
>> >does the login of a user delivers these information to sunRise which
>> >then stores them into the session. These information are usually
>> >the user ID, the first name, the last name etc.
>> >
>> >By adopting this resource, you can store more infos in the session.
>> >
>> >You can get them in an XML processing pipeline by using the sunShine
>> >transformer. So you can write an XML file, like this:
>> >
>> ><doc xmlns:sunshine="http://cocoon.apache.org/sunshine/1.0";;>
>> ><sunshine:getxml context="sunRise" path="/"/>
>> ></doc>
>> >
>> >If you now build a sunLet reading this XML document and using the 
>> >sunShine
>> >transformer, you will get all information stored in the session about
>> >the current user.
>> >
>> >As the info is stored as an XML tree in the session by varying the
>> >"path" attribute of "getxml" you can get one specific info, like:
>> >   <sunshine:getxml context="sunRise" path="/authentication/ID"/>
>> >
>> >HTH
>> >Carsten
>>
>>
>>
>> >
>> >> Peter Baer wrote:
>> >> > We need the user name and some user specific information in the 
>> >>actual
>> >> SunspotDemoPortal session.
>> >> Our question is because the default session attributes (and their
>> >> values) aren't particularly speeky.
>> >> > How can we trigger the portal to add the user name and other 
>> >>specific
>> >> information (like boolean flags) into the session?
>> >> Or are there already some user informations in the session, inserted 
>> >>by
>> >> the portal?
>> >> > And if so, how are they named / how can we get them out?
>> >>
>>
>>
>>
>>
>>-- 
>>+-------------------------------+-------------------------------------+
>>|              >>>  mailto:[EMAIL PROTECTED]  <<<             |
>>+---------------------------------------------------------------------+
>>
>>
>>---------------------------------------------------------------------
>>Please check that your question has not already been answered in the
>>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>>
>>To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>>For additional commands, e-mail: <[EMAIL PROTECTED]>
>>
>>
>
>---------------------------------------------------------------------
>Please check that your question has not already been answered in the
>FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
>To unsubscribe, e-mail: <[EMAIL PROTECTED]>
>For additional commands, e-mail: <[EMAIL PROTECTED]>
>




---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

Reply via email to