[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>
>
[snip]
>
> 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
[snip]
>
> 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?
-Alex
-Alex