Jump to content

Recommended Posts

[B]Overview:[/B]
I am taking on a project to allow restricted access to 500 Microsoft Publisher files (simply a HTML page with synchronized Powerpoint + Audio presentation) online where customers will be granted directory access to certain reports that they purchased. Please note that MS Publisher is just a simple webpage that plays audio/powerpoint slides. Some users will have access to certain reports, others may have access to all reports. I want the admin of the site to be able to grant/remove access in the database to users when they purchase the report.

The key goal to the project is to have the user be able to login, see a list of the reports they purchased with a link to view them. Upon clicking to view a report, their login/key would be passed to the report page they are trying to access and pending on the database, would grant or deny access. A simple example of a directory with a report url would be [url=http://website.com/report/report1/index.htm]http://website.com/report/report1/index.htm[/url], [url=http://website.com/report/report2/index.htn]http://website.com/report/report2/index.htn[/url], etc. etc.

I have a few questions on database design and the best way to handle user privileges.


[B]Database schema:[/B]
REPORTS
-------------
unique_id
company
description
report_url


USER
-------------
id
username
password
email
(?)permissions (?)


[B]My Questions[/B]
1) What is the best way to link the USER table to the REPORT table? Meaning, should I create a seperate table called PERMISSIONS to handle which users are allowed to view which reports? Some users will have access to a few reports, others may have access to all of them. Will there be a list of 500 rows for each user with a '0' or '1' to keep a tally of what reports they have access to? Please advise?

2) Is .htaccess a good way to handle permissions, where a database would store permissions for each user and when they try to view a directory it would authenticate their access and allow or deny?


Any advice or suggestions on my database schema in regards to protected access or privelages would be appreciated! Thanks!
wouldnt it be better to make it so that the pages that the users can see are permitted via the database with a number like 1 mean access and 2 meaning deny then let the admin to be able to change the users permission via the number of 1 or 2.
If possible, it would be easier to use "levels" of authorisation, so a report of level 1 can be read by everyone, a report of level 5, say, can be read by only those users with level 5 (or higher) authorisation.
Barand - I used to do it that way, but what happens when you have a user who needs access to stuff at level 3, and 5, but not at 4? I have found it easier to just categorize things. In my admin section there are areas like Users, Forum, Etc, and admins are allowed into certain areas, instead of having a level. This has made it easier for this approach - others might work differently for different situations.
That's why I put in the "if possible" proviso. I agree it may not fit all situations, but if it does fit here, it's by far the simplest method and doesn't require any intermediate x-ref tables of user and reports.
A compromise might be the levels I suggested but then there may be instances where a user of level 4 needs access to a level 5 report. In which case a record could be created in a "special permissions" table to allow the access.
This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.