Jump to content

Struggling w/ PHP/MySQL Role Based Access Control App I'm developing


Recommended Posts

For whatever I can't conceptualize the idea behind this simple funeral home application - or at least the best way to build it.  I have two versions I'm rolling out.  Anything marked v2 I plan to add later on.

 

I work for a call center.  We have a lot of customers that are funeral homes, and are developing a new service for them.

 

It's a simple yet uber secure user interface app to update our call center on the upcoming memorial services.  

 

I'm not sure how I should go about designing these platform.  It should have 2 or 3 types of users with the following responsibilities:  

 

Administrator Account:  This will be used by any of our operators to update accounts.  Here are some of the key features:

  • Ability to search all funeral home memorial services from multiple funeral homes
  • Add/Update/Delete memorial service records associated with any funeral home

Funeral Home Account:  This will be used by any funeral home that is a customer of ours:

 

  • Add/Update/Delete ONLY their memorial services & memorial designation information.
  • Can not view other funeral home account information (opposite of the admin account)
  • v2 - Website insert code to allow them to display a 'table of contents' of who they have for upcoming services on their own website.  Visitors will be able to view information on the services offered by clicking the name and a template on our site will describe all the services.
  • v2 - Condolenses section.  Visitors to their website will be able to post condolences to the family and/or purchase flowers/gifts/etc for the person.  

I guess my biggest question is on user authentication and access level.  Do I just need to design a completely separate intranet that the operators will use for access, and then have only the funeral homes acct use the primary website?

 

My head has been spinning on this dumb project for the last month :(

You need to build/find a simple login process. Included in that you should have a field in the user table to define the "type" of user: Admin, Funeral Home account, etc. As part of the login process you would store the User Type as part of the session data. Then whenever the user accesses a page or performs a process that should be secured you will check their type (and possibly their user ID) to determine if they should be allowed to view that page or perform that action.

 

For example, you might have a page to create a new event for a funeral home. You may want to allow anyone of the admin type to add an event for any funeral home. But, for the funeral home accounts you probably want to only allow funeral home users to only add for their assigned funeral home.

 

Pseudo code

 

if($type != admin || ($type != funeral_home && $userHome != current_home) )
{
    //Error condition
}
 
//continue with page

 

And, as I said above you also need to verify access on the "actions". You may have a page to list the current events for a funeral home with a delete link for each. In additional to preventing unauthorized access to that page, you also need to check access on the page that actually processes the deletions. Otherwise, someone could send random IDs on the query (or in POST data) and end up deleting records they shouldn't even be able to see.

Great thanks...that's so simple, I can't believe I couldn't wrap my mind around it.  Is there any security vulnerabilities in using that method?  How would you store the account type as a session variable?  If I had two account types, and one type was 'user' and the other was 'admin' wouldn't it make the site vulnerable to someone manipulating session data?  Maybe a unique identifier for the admin account encrypted with sha or something like that would work?

Edited by jdlev
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.