Gregor Horvath <[EMAIL PROTECTED]> writes: > I have the need for such a row level security in my current project, so > I implemented a thin layer above sqlobject. (There is no change in > SQLObject itself) > > If someone is interested, I am willing to share the code.
I am. :-) You can use TG's wiki to share content like this. > It's implemented like the Unix access file rights. > Each database row has an owner and a group and read/write access rights > for the owner/group/others. > > If you don't have the proper rights, selects don't return the row (like > in Oracles row level security). I see. And it should be easily adaptable to something like auto-filtering by customer_id, project_id, etc., right? I believe that both use cases are very similar... > If a turbogears identity is present the user and groups information is > taken from there, if not the information is required in the select's > call. But there is no integration with TG's permissions. So it's a cascade: - TG's permissions apply first to allow acessing classes / methods - row level ACLs are applied to allow retrieving that row > It's not complete but a beginning and enough for my current project. Will you implement INSERT / UPDATE / DELETE? From the above I am supposing you just have it for SELECTs... Those would be cool to have and might make adjusting permissions easier... /me dreams of SGID tables... :-) -- Jorge Godoy <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
