You can alter/create a session validator to look for a user id in the request attributes (request.getAttribute) and if it is there assume another app has taken care of authentication and use the id to build an acl. If it is not there the app behaves normally.
Tomcat has a bug where it will use the same session for cross context invocation of a servlet. This is forbidden in the servlet spec, however. You should not depend on it, you should be careful to use unique keys for anything you put into the session, to avoid conflicts. (I think this bug might actually make it impossible to use turbine in multiple apps this way. Each context will overwrite the others' user object.) Hopefully it will be fixed soon. I entered a bug for it, but it was tabled as the fix requires a lot of code changes. It is ok, and preferrable, that sessions created during a cross context invocation are linked by their session_id. This keeps the sessions tied together for subsequent requests. (Resin works this way.) And two turbine apps will work together in Resin. john mcnally "Michael L. Conneen" wrote: > > Steve, > > RE: .... does not guarantee your ACL passes with you, because the second app > does not know you from Adam. > > That is true. So, using just the base framework, you would have to also > identify the user.. currently this is just via uid/password. I have not > looked into passing the ACL, I would anticipate session issues but have not > verified. > > mlc > > -----Original Message----- > From: Steve [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 15, 2002 11:38 PM > To: Turbine Users List; [EMAIL PROTECTED] > Subject: RE: singleton vs multiple applications > > Mike: > > You said... > > <quote> > For the security, if you use Flux (or Fulcrum) you can have each webapp > point to the same underlying data source via the turbine resources > properties file. > </quote> > > Won't you still have a problem accessing secured functionality in the > separate servlet/webapp because your ACL doesn't transfer? (are you even > still in the same session?) > > What I am trying to say/ask is that leaving the confines of one turbine app > for another, even if both use the same security service, does not guarantee > your ACL passes with you, because the second app does not know you from > Adam. > > Is this not true? > > Steve > > -----Original Message----- > From: Michael L. Conneen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 15, 2002 6:28 PM > To: 'Turbine Users List' > Subject: RE: singleton vs multiple applications > > Matthew, > > Run them as different web apps. If they have to share services or > functions, like say the product catalog, you can either communicate between > webapps or just make sure that the objects and peers are in different jar > files so you can included the jars where needed. > > By the way, I hope to have Fulcrum updated to use LDAP as a data source by > the end of the first quarter. Then, the idea would be the same, you would > still have the TR.props reference the appropriate service/data source and > your webserver point to the appropriate LDAP server if you want to gain the > ACL on the front end. > > Hope that helps. > > Mike > > -----Original Message----- > From: Matthew Koranda [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 15, 2002 6:01 AM > To: [EMAIL PROTECTED] > Subject: Re: singleton vs multiple applications > > I'm mailing this a little funny so I'm not sure if this will be included in > the proper thread but this is pertaining to the thread started by Ronan-Yann > Lorin titled singleton vs multiple applications. > > I was wondering what the final solution was because I am in a similar > situation. I am creating one large app that will connect a company with it's > suppliers, and also make the information available on the internet (kind of > a intranet/extranet/internet solution). It contains quite a few components > that seem as though they might be organized better as separate applications > namely a global/personal address book, a calendar, a product catalog and so > on. I'm not quite sure how these application would interact if they were > separate. My biggest concern is the user login/validation bacause even if > they could operate separately, they would need the same users and groups. > > I had planned on having one main database as the separation of information > is not critical, it will all be hosted ansd operated together. > > I hope my questions are clear. Any help and direction would be greatly > appreciated! > > Matthew Koranda > Orkan Reklamebyr� > Maridalsvn. 87b, Bygn. 6 > 0461 Oslo > > [EMAIL PROTECTED] > Phone (+47) 23 12 19 09 > Mobile (+47) 40 00 82 20 > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
