PostgreSQL Help
 
Forums: » Register « |  User CP |  Games |  Calendar |  Members |  FAQs |  Sitemap |  Support | 
User Name:
Password:
Remember me

The Shed is going Social! Join us on FaceBook and Twitter and chime in on the conversation.

Go Back   Dev Shed ForumsDatabasesPostgreSQL Help

Reply
Add This Thread To:
  Del.icio.us   Digg   Google   Spurl   Blink   Furl   Simpy   Y! MyWeb 
Thread Tools Search this Thread Rate Thread Display Modes
 
Unread Dev Shed Forums Sponsor:
  #1  
Old December 3rd, 2002, 05:11 PM
pablo.gosse pablo.gosse is offline
Contributing User
Dev Shed Newbie (0 - 499 posts)
 
Join Date: Jul 2002
Posts: 155 pablo.gosse User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 6 h 6 m 5 sec
Reputation Power: 11
table design question

Hi all. Here's the situation. I'm building a CMS which will be serving content from a database, and I'm trying to figure out the best way to restrict user access to specific content in the database.

Here's the tables which need to be considered here:

cms_groups (holds group_id and name)
cms_users (holds user_id, group_id, and other info)
cms_areas (holds area_id and name)
cms_content (holds content_id, area_id, and other info)

Now, I was thinking that I would create another table, cms_access, which would have four columns,

- area_id
- content_id
- user_id
- group_id

Then for each page or directory which I wanted to protect, I would just have a record added with an associated user and/or group id.

From here when a user was logged in and needed a listing of all content which they can access, I would hit a view which pulled the content and areas for each specific user, based on what they were given access to in the cms_access table.

Does this seem to be a feasible solution? Can anyone offer any advice as to how it could be improved?

Thanks in advance,

Pablo

Reply With Quote
  #2  
Old December 9th, 2002, 03:23 PM
merl merl is offline
Contributing User
Dev Shed Newbie (0 - 499 posts)
 
Join Date: Aug 2002
Posts: 55 merl User rank is Just a Lowly Private (1 - 20 Reputation Level) 
Time spent in forums: 5 h 48 m 2 sec
Reputation Power: 11
Hi,

Yeah, that is a pretty good way of restricting access.

You might also want to record a history of assignments and auditing information as well.

I would change your cms_access table slightly, making it an assign table. This way you have a history of when something was accessible.

Possible table structure of cms_access_assign:
id
id_type
content_id
deallocation_time
allocation_time

All fields by allocation_time are part of the primary key. allocation_time is the time that the allocation starts being active. deallocation_time is the time it stops working. For assignments that are always on, you can just choose an arbitrarily large future date, like 1/1/4000.

so the way that you would work out what privileges were granted to 'bob' directly is:
select * from cms_access_assign
where id = 13
and id_type = 'USER'
and now() between date_allocated and date_deallocated;

I removed area_id from the privilege because if you moved the content to a new area then the assignment would become 'broken' under the way you were suggesting.

If you bung this into a view the information on current user access should become quite tidy in the application layer.

Reply With Quote
Reply

Viewing: Dev Shed ForumsDatabasesPostgreSQL Help > table design question

Developer Shed Advertisers and Affiliates



Thread Tools  Search this Thread 
Search this Thread:

Advanced Search
Display Modes  Rate This Thread 
Rate This Thread:


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
View Your Warnings | New Posts | Latest News | Latest Threads | Shoutbox
Forum Jump

Forums: » Register « |  User CP |  Games |  Calendar |  Members |  FAQs |  Sitemap |  Support | 
  
 


Powered by: vBulletin Version 3.0.5
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.

© 2003-2013 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap