Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 82954 invoked by uid 500); 20 Mar 2002 06:51:48 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 82939 invoked from network); 20 Mar 2002 06:51:48 -0000 From: "Carsten Ziegeler" To: Subject: RE: RE: How to put user data into SunspotDemoPortal-session at logon time Date: Wed, 20 Mar 2002 07:53:57 +0100 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C9731BB.8090701@siemens.com> Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 20.03.2002 07:51:56, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 20.03.2002 07:51:58, Serialize complete at 20.03.2002 07:51:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Peter, all your pipelines are wrapped (secured) by the sunRise-auth action with the handler and the application parameter, for example the sunLets: 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: .... HTH Carsten > -----Original Message----- > From: Baer Peter [mailto:Peter.Baer@nbg.sbs.de] > 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. > > > > > > 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: > > > > > > > > > > > >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: > > > > > >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:Peter.CA.Baer@Siemens.com <<< | > +---------------------------------------------------------------------+ > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. > > To unsubscribe, e-mail: > For additional commands, e-mail: > > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: