[ewiki] Re: ewiki_auth() calls

Great!  The powersearch.php calls  can now be changed to use this new
method.  Previously we were getting all pages in search but now only the top
10 need GETs in the function.

         #-- refetch page (still cached by OS or DB)
         if  ($n < 10) {
            $row = ewiki_database("GET", array("id"=>$id));
         }else{
             unset($row);   
         }
    
         #-- retrieve and check rights if running in protected mode
         if (EWIKI_PROTECTED_MODE && !ewiki_auth($id, $row, "view",
$ring=false, $force=0)) {
            if (EWIKI_PROTECTED_MODE_HIDING) {
                continue;
            } else {
               $row["content"] = ewiki_t("FORBIDDEN");
            }
        }


Andy

> -----Original Message-----
> From: Mario Salzer [mailto:mario@xxxxxxxxxxxxx]
> Sent: Thursday, December 11, 2003 11:04 AM
> To: ewiki@xxxxxxxxxxxxx
> Subject: [ewiki] Re: ewiki_auth() calls
> 
> Hey,
> 
> > perform their own GET if they need to?  We already pass them empties
> many
> > places and I know some of my GETs could be removed if we established
> that
> 
> I `grep`ed through the plugin directory to see, where we call the
> ewiki_auth() with somehow empty parameters. And the investigation result
> was: just two places:
>    [auth_perm_unix.php]
>          ewiki_auth(NULL,NULL,NULL,NULL,2);
>            # Which now is a very specialized call to ewiki_auth(), that
> just
>            # triggers the forced re-login part, regardless of what any
> perm
>            # plugin tells.
>    [control2.php]
>          ewiki_auth(NULL,NULL,$action);
>            # Which just asks for the $action to be allowed. And I believe
> in
>            # this case it's ok, unless there wasn't a highly sophisticated
>            # perm plugin, which needs to compare that with an obscure
> {meta}
>            # field.
> 
> So the actual problem I see is, that the ewiki_auth() was meant to also
> support trivial permission plugins, that just care about $id and/or
> $action,
> or alternatively just for the $requested_ring_level. That is also why the
> $id parameter is there two times - the plain one and a second copy inside
> of $data.
> 
> Now, if you had a more complicated permission handler, then you could of
> course need the full $data entry. So we could simply add a "GET" call
> inside
> of ewiki_auth() to satisfy that, but as most other perm plugins won't need
> the full $data entry this then was just a slowdown.
> But it seems easy to call "GET" yourself in your permission plugin, if
> you detect that $data was empty (which rarely will happen!). This looks to
> me like the best solution.
> 
> So the conclusion should be, that we try to ensure passing of a $data
> where
> it's available - but we should not force it (and add explicit slowdowns),
> because (possible) lightweight perm plugins would never benefit from that
> and they are part of the concept.
> And we should especially take care, that the _PROTECTED_MODE enhancements
> never influence ewiki's speed in the default authentication-free mode.
> 
> mario
> 
> 
> > What about specifying that perm plugins can expect to receive either the
> > full database entry or an empty variable in $data and must be ready to
> > perform their own GET if they need to?  We already pass them empties
> many
> > places and I know some of my GETs could be removed if we established
> that
> > such a rule.  The more I thought about it on my way home last night the
> > better I liked it.
> >
> > Andy
> 
> 
> 
> _________________________________________________
> Scanned on 11 Dec 2003 16:25:19
> Scanning by http://erado.com

Other related posts: