[prev in list] [next in list] [prev in thread] [next in thread] 

List:       twig-devel
Subject:    Re: [Twig-devel] New database setup using adodb
From:       "Aaron Stone" <aaron () serendipity ! cx>
Date:       2005-06-16 21:59:41
Message-ID: twig.1118959181.81862 () serendipity ! palo-alto ! ca ! us
[Download RAW message or body]

On Thu, Jun 16, 2005, ""Brian Ginter"" <brian.ginter@southern-air.com>
said:

>> I'd prefer not to have a variety of separate entry points. We're starting
>> to add them for every little thing and I'm a bit worried. The single entry
>> point was always an attractive part of TWIG's design.
>> 
>> If there's a branch between mailine operation and a pointer to
>> configuration, then it's no more difficult to integrate the configuration
>> right into the mainline operation and jump to it.
>
> OK. How about this. index.php is the only entry point but if
> $TWIGNotConfigured == 1 then we send a redirect header to setup/index.php
> and when we are complete there we are linked back to the main index.php
> atwhich point we pick up with the configuration as it is now.

I'd rather have a setup feature. If $TWIGNotConfigured, then we disable
all features except for the setup feature. I've done this as a hack before
for my Welcome feature, which forced you go through a wizard of the site
policies, policy agreement, and change of password. Once that's done all
features for your user class were enabled.
  
>> Besides, I want to get my wizard code into the codebase and use that ;-)
> 
> Sounds good

I'll try to get this together ASAP.
 
>>> It has been mentioned that we need to have the ability to create
>>> administrative user(s) during the installation process. If security=basic
>>> we currently create a file in features/admin/users/ that is the users
>>> login name with a .admin appended. This obviously will not work if we wish
>>> to create the users from a web interface. So do we somehow use the
>>> acl_groups table for either type of security?
>> 
>> We need to write a migration function into the upgrade-from-2.x code that
>> copies whatever we knew about security=basic (checking for the admin files
>> and reading the $disabled array) and populates the security tables in a
>> simplified manner. Right now Greg has a stop-gap measure with the
>> db.basic, but I'd like to move towards a single provider that can operate
>> in either simple mode (one group to rule them all) or complex mode
>> (multiple levels of groups).
> 
> Someone who understands the security better than I will have to take this
> on.

The problem is the magic numbers. In TWIG 4 the security function is:

TWIGCheckSecurity( $right, $feature, $action, $username );

Where you can leave out everything but $right and $feature. This is
tremendously easy to code with; you never have to explicitly add
$login["username"], you can check for access to the entire feature without
checking each action, and you don't need a two function idiom that does
convertions between text and numeric rights (e.g. 2 == read, 128 == admin)
-- always use text rights, and the function will figure it out even if you
use numeric rights.

I'm tempted to change over to this new security function and bring down
the reign of the magic numbers.

>> In either case, security=basic => cvs remove lib/security/basic.inc.php
> 
> Go for it. Does this make the $disabled array obsolete?

Greg went through and did the work of sorting between things which are
*only* described as $disabled's, and things which were multiply described.

It's interesting now to see that some things make more sense as $disabled
than with full rights controls. But $disabled is just a specialization of
the TWIGEveryone group. I don't see the need to differentiate in code; the
differentiation should be in presentation mode (simple, advanced).

Aaron

_______________________________________________
Twig-devel mailing list
Twig-devel@informationgateway.org
http://informationgateway.org/mailman/listinfo/twig-devel
[prev in list] [next in list] [prev in thread] [next in thread]