Hi Marc, I posted a question on this newsgroup recently (http://www.mail-archive.com/[email protected]/msg08961.html) about _replacing_ the turbine_* tables with our own (we already have an existing application with existing database tables + data, that is why we are not using the turbine_* tables).
I have achieved this, but not without compromises. One of the compromise is that we are only using Turbine's security system for authentication and when we need to do authorisation we use our own security model. In addition the replacement Turbine security classes is read-only, so as soon as you try to do any modification to the underlying system via Turbine's bundled DBSecurityService an exception will be thrown. Note: This is still beta (if not alpha) level code. I am still in the process of verifying what I have done works for all situations in Turbine. In addition I am also drafting up an email to the newsgroup to show what I have done so anyone else who is interested can also follow suit. However I am not willing to post this until I am sure what I have done does work thoroughly (don't want someone to follow my instructions and end up bombing their system). If you like we can discuss this directly, and any things we sort/figure out I can feed back into my email to the newsgroup. cheers, CP Marc Lustig wrote: > Hi Scott, and everybody, > more than a year ago you wrote the message below. > (There has been no reply to your message.) > What I need to do is building a security framework for customers to inherit > their rights (roles,permissions) to sub-customers. I have app-tables that > hold reseller-specific security data. This is supposed to be kind of > extension of the basic turbine security framework. (I can't explain the > whole thing, it's rather complex.) > Anyway, I need to reference various turbine security tables. > So I wonder if you have figured out a solution for the problem that you > outlined in your message. > I was thinking about aliasing all the tables (like for extending the user) > but I'd like to make sure there isn't any better/easer solution before. > > TIA. > Marc > > > * From: Scott Eade > * Subject: torque schema - joins to turbine tables > * Date: Tue, 03 Jul 2001 12:21:39 -0700 > > In my application database schema a number of my tables > include foreign-key references to TURBINE_USERS and > TURBINE_GROUPS. To make this work I currently > redefine these tables at the bottom of my application > database schema (a cut and paste from turbine-schema.xml). > > With this set up the two tables mentioned are generated twice > and I end up with two sets of peer classes - not a very tidy > solution, but it works. > > I'm wondering if there is a better way of achieving the same > result. In database.dtd I notice a number of table element > attributes that may actually provide what I need, but I am > unsure of the combination of attributes to use. > > Here is the definition of the table element from database.dtd: > > <!ELEMENT table (column+,(foreign-key|index|unique|id-method-parameter)*)> > <!ATTLIST table > name CDATA #REQUIRED > javaName CDATA #IMPLIED > idMethod (idbroker|autoincrement|sequence|none|null) "null" > skipSql (true|false) "false" > abstract (true|false) "false" > baseClass CDATA #IMPLIED > basePeer CDATA #IMPLIED > alias CDATA #IMPLIED > > > I was thinking that skipSql might be part of the answer, > however I remembered that my currently generated > BaseTurbineUser class has a whole bunch of get methods > that join back to my application tables. I am now thinking > that I may be better off keeping the duplicate table definitions > but providing baseClass and basePeer attributes presumably > so that the application classes extent the classes generated by > turbine-schema. > > Am I thinking along the right lines or have I got it all wrong? > I am assuming that linking from application tables to > turbine tables is a common requirement and that database.dtd > and torque allow for this. > > Thanks, > > Scott > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- R E D S H E R I F F C.P. Lim - Software Engineer Level 1, 10 Queens Road +61 3 9864 0733 tel Melbourne VIC +61 3 9864 0778 fax Australia +61 413 781 846 mob This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this message in error please notify us immediately by return email or telephone +61 (3) 9659 0432, then delete this message. Any views expressed in this message are those of the individual sender and many not necessarily reflect the views of Red Sheriff. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
