Bernhard Huber wrote: > > hi, > i have some question about the portal..., btw it's great donating > your work! > > >Although the current primary use of Cocoon is as a Web > publishing framework > >we see great potential for integrated components that provide > such things as > >authentication and portal capabilities. To honor this we are willing to > >return parts of sunShine back to the Cocoon project. These parts will > >include Cocoon components for authentication, session management and > >building portals. All of these components adhere to the Cocoon > architecture > >and are "tried and trusted". > > > What kind of authentification schemas are supported?
Theoretically, all schemas are supported. The whole authentication is configured in the sitemap. You can protect pipelines with a so called handler. You can have different handlers in the sitemap, so you can use different authentification schemes in one sitemap. A handler in turn points to the real authentification mechanism. Here you can hook in either a pipeline or an own java class. In the case of a pipeline, you can use for example SQL statements (SQL transformer or esql) to fetch the authorization data or you can read them from an XML file or use LDAP or or or. > Can I handle form-based authentification as described in the servlet-spec? > The components do not directly support that, but I think with the hooks explained above that should be possible. > > > >The authorization components allow the integration of given data-sources > >(e.g. databases that may already contain user information) and provide a > >means of protecting pipelines so that only authorized users can > access the > >defined resources. > > > how, and where do i define the authorization? > How can I map from authentification, to authorization? > Everything is done in the sitemap. You can use actions, to protect pipelines. And again pipelines are used to fetch the authentification data. > > > > > >The portal engine is totally SAX-based and is integrated into > the sitemap. > >Portals can be described in an XML format. Content can be defined for the > >portal using regular Cocoon pipelines. Based on the authorization > >components, a portal generator "gets" the portal description for > a user and > >streams the complete portal content into the pipeline. A following > >stylesheet transformation transforms this into HTML. > > > Is there some caching for portal parts which are the same for all users? > The portal is currently build up from several parts: there is the global profile, a profile for each role/group and a profile for each user. If some users belong to the same role/group they get at first the same role/group profile until they change it. > Can a user change the portal definition, he/she owns?# > Yes, and it is also configurable which parts of the profile the user can change. For example you can define that a user can only change the content he wants to see. Or he can also change let's say the background color etc. HTH Carsten > bye bernhard > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
