Jump to content

Complex user rights for custom built login system


This topic is 7941 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I've designed my own login in system for my database. It's made up out of several fp5 databases which uses the global fields SessionUsername and SessionLevel to track users and for their access rights.

In SessionLevel I store a number from 0 to 9 which represents the access level of the user (0 = no access to the database, 9 = all the rights).

Now I'm designing a database for the whole company which will be used by almost every department. In this database I'm also going to use the same custom built login system to track users and for their access rights.

But with a small difference which makes it more complex.

I want to have for every department a seperate user rights level, so one for accounting, ICT, Bido and a seperate one for the Maintenance menu. This means that in it's current form I'll need to make a Session Global Field for every department. This is a lot of work and it's quite a rigid system, not flexible in what the user may do.

(for a graphical explanation on how this database 'looks'please click on the following link: http://www.x-pc.info/zooi/fmforums/dbasestruc.gif )

My idea was to use a sort of Active Directory structure for my database. To store in words what a user may or may not do in a global field.

For example.

The following information is stored in the global field SessionLevel:

MaintenenceNo, AccountingYes, ICTNo, BidoNo, SchedulerEditOwn, SchedulerViewAll, ProceduresView.

The information stored in that global field means the following:

You have access to Accounting, but not maintenance, ICT or Bido.

You may edit your own scheduler tasks and you may view all the tasks stored in the database.

You have only read rights in the procedures database.

I'll use a partial match to see if a user may do something. In other words: SessionLevel = AccountingYes. If it finds the string it will grant you access, if it doesn't it will deny you access.

If you now change the rights for the departments the user has access to, to for example AccountingNo and ICTYes. The user now still has his old user rights in the Scheduler and all the other databases (if he can access them in the current department. An user can't open databases which aren't listed in that department due to scripted layouts). But he can't access the Accounting department menu anymore, he now may only access the ICT department.

Now my question is, how can I make a user database which is userfriendly in generating and storing that information?

The best way for me looks like making a field called Accounting and then to use a list with the options which are available. In this case a yes or no option. The script then reads all the fields and puts the word Accounting in front of the entered option (all fields must be filled in, the database will fill in no when an user is added).

Link to comment
Share on other sites

Right now you have a system that uses 0-9 to define access. All that you need to do is to expand this to 0-9 for each DB that that you are building. Instead of "hardcoding" what 0-9 means, build a small DB which defines what 0-9 means for each DB in the system. Then instead of simply checking the 0-9 number, your security system will check this new DB and match the 0-9 with the current DB and see what the security defination it.

You were on the right track to begin with, keep going!

Link to comment
Share on other sites

You alredy have a 0-9 access level setup for your existing solution. All that you need to do is to expand this to encompass all of you additional solutions. Since you need to define the 0-9 differently for each "sub-system" the best way to do this is via a seperate "security" database which defines what the 0-9 levels are for each DB or each user or whatever.

Link to comment
Share on other sites

So what you mean is making a field in a security database.

For level 4 a field called Level 4 with the following information stored: MaintenenceNo, AccountingYes, ICTNo, BidoNo, SchedulerEditOwn, SchedulerViewAll, ProceduresView

And then to use scripts to analyse whats stored in the level field.

Link to comment
Share on other sites

I've used for the login system a Privileges.fp5 file, one record per privilege, each privilege identified by a unique code and described by a text field, using the records of Privileges.fp5 to build a check box field in the Users.fp5 file so that the administrator can check for each user his/her privileges

Any script checking for that privilege starts with

If (PatternCount (Users::PrivilegeFiled,"ThePrivilegeCode") < 1

Exit Script

End If

You can see an example of what I'm saying downloading "The gateway" at www.fmfiles.com

Link to comment
Share on other sites

So what you mean is making a field in a security database.

For level 4 a field called Level 4 with the following information stored: MaintenenceNo, AccountingYes, ICTNo, BidoNo, SchedulerEditOwn, SchedulerViewAll, ProceduresView

And then to use scripts to analyse whats stored in the level field.

That is one way to do it. Another would be to have a record in the DB for each combination (i.e. Maintenance0, Mainenance1, etc) that you want to track. This is a more complex method but allows the greatest amout of flexability including being able to assign rights to specific users for a specific DB.

Either way your scripting will check this DB and determine what is possible for the user to do.

Link to comment
Share on other sites

With what was said here and with some information from the following thread: http://www.fmforums.com/threads/showflat.php?Cat=&Board=UBB19&Number=38177&page=0&view=collapsed&sb=5&o=&fpart=1'

Is this what I'm going to do:

I'm going to creato a user.fp5 where the username, password and notes about the user will be stored.

In seperate layouts I will make a field (check boxes) were you can give the user permission for an action or not. Below such a button a input list is stored. That list contains 2 options. For example 0 or 1.

In 2 gobal fields I'll store the username and password.

When a situation arises where verification is needed for access. The database will use the password in the global field to check what rights the user has in the user database.

I'll also make the layout with the following concept (using different layouts):P

One User tab; Username, password, notes

Security; accounting, ict, bido, maintenance, and tabs for the all the databases seperate.

I'll script the layouts in such a way that when the user doesn't have access to for example bido you also can't give him permissions in a database that is only used in that department.

This seams to me the most flexible solution and the most userfriendly for my co-workers (some aren't what you call experienced with the computer).

Link to comment
Share on other sites

The devellopment of the user database is coming along nicely.

I've got now a logon system with a realtime user rights system implemented in the database. This to the delight of my co-worker who is going to manage the user rights and the ceo of my company. smile.gif

But now I'm stumbling across a function I want to implement but I don't know how to script it.

In the user database there is a field which gives the user the right to edit a record or only view it. Now if you may not edit records in the user database it's not really a usefull function when you can see the password and username for an user which can edit the records in the user database (he can then logon with the username and password and have all the rights). Now I wan't to script the database in such a way that when the user doesn't have the right to edit records in the user database that the color of the tekst is changed to the background color. When that happens he can't read the password and username of a user and can't logon with all the rights.

Only I don't have a clue how I schould do this..

Link to comment
Share on other sites

With other words make a layout where those fields don't exist or with dummy fields (empty non related fields).

But if I would use such a solution it would double the amount of layouts I'll need in the database (And all the other databases which have a similar security issues).

The layouts are quite complex (every function is scripted in the user database to prevent security holes). And I don't feel much for copying and pasting entire layouts continuously when I change something in the layout. So this is really a last resort solution for me.

Link to comment
Share on other sites

Sorry I don't get it.

Why do you have to duplicate those layouts?

Well, I didn't follow this thread but I guess that passwords and access privileges are in separated records for every user you have.

Dj

Link to comment
Share on other sites

The access privileges and the user information is stored in the same record which are also stored in the same database. The database is split in several layouts to keep it user friendly and readable (not a load of options in one screen). At the moment I just have 2 layouts of a total of 5 layouts which contain fields where you can view the username and password (the other layouts are for global fields used to store logon information and denied access screens). So if I would make a scripted event which would redirect the user to a different layout depending on his access privileges (in this case if he may edit a record or not) it would mean that instead of 2 layouts I'll have 4 layouts.

Link to comment
Share on other sites

Sorry I didn't express myself very well.

What I meant was 1 user 1 record.

However to answer your question:

Create an num field auto enter value 1 named userAccess

You already have an field for allowing edit so let's call it edit.

Now create an relationship CanEdit::edit-->userAccess.

Hence, to hide/show info based on value in edit field, put relevant info in one-row portals (you can have them as many as you want on your layout) from rel CanEdit.

The fields you put in portals have not to be from relationship CanEdit.

So summarizing, you don't need additional layouts but every where you need fields with conditional access put an one-row portal from rel CanEdit and drop fields you need inside.

HTH

DJ

Link to comment
Share on other sites

This topic is 7941 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.