why can't you just combine the project id and role name to create a complex role that is returned. that way each time you need to check project '10' for role 'admin', your combined role would be '10admin' and that's what you would check for in your code and web.xml.
So then your view returns all combinations for the user and better yet, you don't have to write your own realm. Charlie > -----Original Message----- > From: Jacob Hookom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, August 22, 2002 12:53 AM > To: 'Tomcat Users List' > Subject: RE: Realm Security Implementation Question [OT] > > > Comments below > > | -----Original Message----- > | From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > | Sent: Wednesday, August 21, 2002 11:04 PM > | To: Tomcat Users List > | Subject: Re: Realm Security Implementation Question [OT] > | > | On most reasonable databases, you can create views that organize the > data > | in the way that JDBCRealm needs, and that's a *lot* easier than > writing > | your own LoginMethod implementation in JAAS. > | > > It's not a problem to creating views, but I am hesitant to use > JDBCRealm. From looking at the source, it requires one row to contain > all valid roles. In this case, I would have to setup > extensive amounts > of triggers since role management for the site is extremely > volatile and > set by users of the site as they go. > > I had posted about creating Realms before which you > graciously responded > to, but I'm still stuck as to how to handle this schema: > > tbl_user > uid email password > > tbl_project > uid name > > tbl_project_user > useruid projectuid role > > tbl_resource > uid name > > tbl_resource_user > useruid resourceuid role > > So, if a user is accessing a project referenced by its uid > (project.do?id=443), I must be able to check a role to see if the user > is even a member of that project, and then get the role(s) he has for > it. There isn't any uri/directory based validation required. > > We are developing only for ourselves so we do have the flexibility of > working directly with our own principal. The other option is again, > coming up with a String representation that can be tokenized in > representing a role for a particular project id. > > -Jacob > > | > Our > | > applications are deployed under a single war to take > advantage of a > | > pseudo single sign-on. > | > > | > | Tomcat 4 supports "real" single sign on if you want it -- see the > section > | entitled "Single Sign On": > | > | http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/host.html > | > | http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html > | > | > | > | > Any suggestions would be apprechiated, > | > > | > Jacob > | > > | > | Craig > | > | > | -- > | To unsubscribe, e-mail: <mailto:tomcat-user- > | [EMAIL PROTECTED]> > | For additional commands, e-mail: <mailto:tomcat-user- > | [EMAIL PROTECTED]> > | > | --- > | Incoming mail is certified Virus Free. > | Checked by AVG anti-virus system (http://www.grisoft.com). > | Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 > | > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.381 / Virus Database: 214 - Release Date: 8/2/2002 > > > > -- > 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]>
