[whups] Code update (numerous features)

Alex Leverington admin@networkessence.net
Tue, 20 Nov 2001 19:05:19 -0600

Quoting "Robert E. Coyle" <robertecoyle@hotmail.com>:

> From: "Alex Leverington" <admin@networkessence.net>
> But the auth stuff can and should be completly hidden behind Horde::Auth.
> There is already a Auth backend for an sql database.  Chuck suggested
> allowing
> two separate auth configurations (and I guess this could be extended to any
> number of auth sources if that would be useful), one for public and one for
> non-public.  The Perms:: methods would then give all relevant info for what
> should be displayed to and allowed from the current user.  This is
> necessary
> to completely integrate with the Horde framework - it will restrict the
> possible setups if whups uses it's own private auth system.
> > [snip Whups.php -> WhupsPublic.php]
> > 
> > The file changes were only for infrastructure and a good idea of what is
> to
> > come.  The WhupsPublic.php will massively change...also I copied
> Well, I don't think this is the right approach.  Most of the code in
> Whups.php is
> essential for a working system and won't change no matter who you're logged
> in
> as, for example the useForms function.  In fact, the only part of Whups.php
> that
> could possibly change is the section headers.

I agree...

> To make this as easy to maintain as possible, I would suggest code more like
> this:
>    if (Perms::hasPerm('system', Auth::getAuth(), 'view-admin-section'))
>        $sections['admin'] = $adminsection;
> (note, I haven't looked closely at how the auth and perms work yet, so this
> is
> only an example.)  The same goes for the details.php page.  This contains all
> of
> the 'whatnow' logic which won't change, just whether you're allowed to do
> it.
> In fact, it could even be done transparently through the Form->isValid()
> method
> which could do the permission check and return false if you're access is
> denied.

Sounds great. I'm learning.  I'll redo my code changes accordingly.  One 
question though, originally, user backend all operated on the user's ID being 
his/her email address.  Was this something you had in mind?  I changed it to a 
user id system with getUserFromEmail() getUserFromName() getUserDetails(), 
getUserDetailsFromEmail(), etc... what do you think?  And what do you think 
about having only the comments be available to unauthorized users?