Controlling Access to Customer Details (was Make New Class of User)

greenspun.com : LUSENET : SmartPart Development : One Thread

The idea is that only Ceetak should be able to see everybody's pumps. Other users may have admin rights, and are able to add parts and generally maintain their own data.

This requires that we classify users into probably four categories. This needs a bit of thinking through, and I'm not sure this is right, but my working model is:

1) read-only non-admin users 2) read-write non-admin users. These will be able to put in some limited data, but I'm not exactly sure what it is - perhaps order an existing spare part. [check!] 2) 'normal' admin users that can do everything that an admin user can do now. 3) 'super' admin users (essentially just Ceetak/Andy Sears) who will be able to do everything *on anybody's pumps*.

This needs to be spec'd. Neil, can you put together a 1-page proposal on how this will work - maybe extend your Delphi model to show which bits can be reached by which class of user - and try to gauge how how much of a change this will be.

Ta,

Steve.

-- Anonymous, February 21, 2002

Answers

Response to Make New Class of User

Superficially, the user levels appear as follows:

1.Read only access to pumps, plus read/write access to Log Entries, all for one predetermined customer

2.As 1, plus ability to add a pump for one predetermined customer

3.Full access to all customers and all facilities

My questions to Andy are:

A.Is the above correct, or does the code do more behind the scenes? B.Which level 3 functions would be needed by a single customer 'Admin' type user? At the absolute minimum, the 'User maintenance' function should obviously be omitted, but what of teh other functions?

-- Anonymous, February 21, 2002


Response to Make New Class of User

I've looked more closely at the code in preparation for adding a new level:

Level 1 : Read only access in all but Log Entry, where it can update an add an entry. It cannot do this from the log entry search results page, but can from the log entry details page.

Level 2 : As level 1, plus ability to use 'Order Pump' button in pump details page, and the addition of the 'Add Pump' frame menu item

Level 3 : All functions for all customers (except Add Pump).

Each level has a separate frame menu, and welcome page.

The code has 3 mechanisms for processing access rights :

Non-x5AkTY45 code: 1.Checks for level (such as for when showing 'Order Pump' button)

2.Returns to x5AkTY45 page when no rows returned if request.form ("location") = "admin" - this hidden field is set in the x5AkTY45 page that reroutes to non-x5AkTY45 pages after a customer has been selected.

3.Displays 'Select report for customer-name' if request.form("acc") has been set by calling x5AkTY45/Resports page from the session ("Acccode") value.

x5AkTY45 code:

1.Fortunately, apart from the above Admin level identification by request.form field, the only reference to level is to level 3

2.Unfortunately, this check for level <> 3 is in many pages. It is simply there to ensure that only Admin (level 3) users can see the current page.

They should have enumerated 3 to a text value, or spaced out the levels to allow insertion of a new level. We either keep this level 3 and add a level 4 (undesirable), or we change level 3 to 4 and add new level 3 processing. This means a lot of file changes, plus user table changes. Recommended though.

-- Anonymous, February 25, 2002


Response to Make New Class of User

Steve, I've changed about 45 asp files to refer to global.asa constants for security level checks rather than hardcoded values. I've done some rudimentry tests and all OK. The next step is to layer on top the changes for the new user level, with appropriate global.asa changes.

I'll hang on to these changes until then. No need for the perl script just yet - whilst changing files for security, I have used a custom button in AceHtmlPro to insert the $Header$.

Next step is to write our understanding of the security requirements in an email to Andy. Can you do that?

-- Anonymous, February 28, 2002


Response to Make New Class of User

Steve, I have found no global.asa file in Smartpart, so have added one to the Ceetak root folder on my PC (attached), with definitions for the 4 security levels in Application_OnStart. I have changed x5AkTY45/customer/findresults.asp to refer to these definitions, and tested it works as before. No problems. I also changed the global.asa to different values to see when the change was picked up - and it works fine when restarting Smartpart. (My ASP book was a bit vague about what application start up meant - the example and words implied that this OnStart sub is run only once ever - they used it to hold a site counter).

I have attached these 2 files - can you please install and test access rights (typing the URL of x5AkTY45/customer/find.asp after logging in 3 times with different security levels).

Meanwhile, I will assume all OK (it is here), and change all files to refer to the application variables (constants), marking each file with at the top.

-- Anonymous, February 28, 2002


The plan now is to have the following categories of users. Internally these will be defined by symbolic constants, which will correspond to numbers stored in the database.

The categories are:

(i) read-only (READ_ACCESS). This is truely read-only access to data attributed to a particular customer. No ability to update anything in the database or generate any emails.

(ii) read-only+log details (READ_PLUS_ACCESS). This is as per (i) plus the ability to to add a log entry (or several) plus add a pump, except that the 'add pump' action generates an email to Ceetak, rather than actually adding a pump dynamically.

(iii) write access, single customer (WRITE_ACCESS). This is log-entry and add pump dynamically (i.e. not via email). It also includes the ability to add pump models and spare parts Note that spare parts are really 'spare part models' i.e. types of spare parts rather than actual instances of spare parts, and as such, like pump models, are visible to all customers. This is the only part of the system that an action by one customer is visible to another customer and vice versa.

(iv) All existing 'Level 3' functionality (ADMIN_ACCESS). This will in practice be restricted to Ceetak employees. Pumps, Pump Models, Users, Lists, etc. etc. can all be created and modified.

-- Anonymous, March 04, 2002



Moderation questions? read the FAQ