[Tsheetx-developers] Fwd: security model

[Scott M. <sco...@gm...>]

forgot to include the list...

---------- Forwarded message ----------
From: Scott Miller <sco...@gm...>
Date: Thu, Feb 17, 2011 at 5:16 PM
Subject: Re: [Tsheetx-developers] security model
To: Mark Wrightson <ma...@rw...>


I too had thought about using a group model for security, but I didn't have
working code to use.

But, after thinking about it awhile, does this proposed implementation
actually do a better job of defining group access than the existing
version?  Although it is not as well defined, I think the existing model and
this new proposed model may not be sufficiently different from each other to
warrant making all the needed changes.

-Scott


On Thu, Feb 17, 2011 at 2:20 PM, Mark Wrightson <ma...@rw...>wrote:

>  Hi Dave,
>
> I see your point that it does add extra complexity, however it won't
> introduce extra bugs because the code
> is already tried and tested.  If you would like I am able to demonstrate
> the auth stuff on another site?
> The main benefit the update will bring is scalability.
>
> Only one line of code is required to check for authorisation:
>
> if(Auth::ACCESS_GRANTED == Auth::requestAuth('monthly','view'){
>     yes
> }
> else{
>  no
> }
>
> Every page in tsng already has the one line of code at the top of the page
> to check whether a given user can access a page or not.
>
> Regards
> Mark
>
> _____________________________________________
>
> Mob:  07725 695178
> Email: ma...@rw...
>
>
> On 17/02/2011 11:00, David Thompson wrote:
>
> My feedback: it looks very complicated, for something that at the moment is
> relatively simple.
> So does it justify introducing a lot of code, and bugs, for the feature
> that it brings (finer user access control)?
>
> ------------------------------
> Date: Thu, 17 Feb 2011 09:32:57 +0000
> From: ma...@rw...
> To: tsh...@li...
> Subject: Re: [Tsheetx-developers] [SPAM] Re: security model
>
> Hi Peter,
>
> The privilege levels i.e. user, reporter, manager, administrator would be
> created as different user groups.  A user can be a member of several groups.
>
> so
> user table:
> 1 admin
> 2 joe bloggs
> 3. test user
>
> user group table:
> guest
> user
> reporter
> manager
> admin
>
> user group assignment
> admin -> administrator
> admin -> manager
> joe blogs ->user
> joe blogs ->report
> test user ->user
> test user ->report
>
> privilege table:
> 1. monthly,view
> 2. stopwatch, view
> 3. clockings, edit
> 4. reports, view
>
>
> privilege assignment:
> reporter -> 4 (reports,view) granted
> user ->1 (...) granted
> user ->2 granted
> manager ->3 granted
> test user ->4 denied
>
>
> If a request to access an area that hasn't been defined in a users access
> control list then it is a denied access.
> If a user is denied access at any point that is it.  Denied.  i.e. test
> user above is granted access to reports through the reports group but
> is denied access on a specific user basis.  Therefore he is denied access.
> A deny should always overrule an allow in my opinion.
>
> The (monthly, view) bit is just a way of allowing pseudo groups of
> privileges to exist so that they can be searched more easily. The fact that
> it is two fields 'monthly', 'view' has no real effect.
>
> In terms of default user groups this would be configured.  An unlogged in
> user is part of the group guest.  A new signup is part of the group user.
> So therefore I would add an extra group above 'tsx_users' so that a new
> signup has to request access to be able to start using the timesheet
> functions.  Alternatively an admin could register a new user and give them
> access straight away.
>
> Please could I have some feedback on my proposed update?
>
> Regards
> Mark Wrightson
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>