[ewiki] Re: $ewiki_errmsg, ewiki_auth() hooks

Hey,

> Could we add a $ewiki_pagestate variable that tells the template whether we
> have successfully returned a page or why not?  Specifically I'd like to

That is complicated because ewiki_page() cannot exactly tell if it really
returned a valid page or just an error message. If a ["page"] or ["action"]
plugin takes over, then it is as clear as with the default page view, that
everything went well. But there is also the case that a ["handler"] could
have triggered and returned something. Now as they are supposed to be the
all-in-one-can-do-everything plugin hook, we cannot actually tell if they
throwed an error message or rendered some pages together.

The $ewiki_errmsg is not any more helpful here, as it may still be unset
if a handler emptied it after returning the errmsg as faked page content
back to ewiki_page().

> display a login prompt in my title bar whenever a user tries to view a page
> that they do not have permission to view.

But for this you could easily use the ["auth_query"] plugin hook, as that
was designed to be called in cases in which the current authentication level
isn't sufficient for the requested action (permission denied). This hook
is for 'login form' printing in fact. See the fourth parameter, it tells if
the user is to be queried by presenting a login form.
Utilizing/integrating this plugin hook with your current ["auth_perm"]
plugin may be complicated (I know that), but in this case was the best
way to go.

plugins/contrib/auth_method_http.php currently implements it, but as HTTP
query and not as HTML login. I'm however working on such a html login
alternative for the ["auth_query"] hook.

#

> I need my authentication code to know when it is trying to authenticate for
> page creation, but there is a problem.  As it turns out, most page plugins

Personally I'd favour the $ewiki_plugins["page"] index checking, that you're
currently using. This interface won't change and so returns solid results.

But if you're really concerned about the pure page creation, you should
eventually leave out that check from your auth plugin and rather register
a secondary baby auth function that camouflages as ["edit_hook"] plugin
and prints an error message whenever it wants to. This had the main
advantage of making your main auth_ plugin smaller, and IMHO putting parts
of authentication into other plugin hooks isn't an all too bad idea.

> $ewiki_plugins['page'] for the id but I'd rather if ewiki_page would add the
> name or function name the plugin to be executed to $data['page_plugin'] so I
> could check that instead.  Other options could work too, any

The problem with $data is, that our stupid ewiki_database doesn't now a bit
of what is in the database; it just reads the array and builts a SQL query
out of all its contents. If now one plugin added random entries into $data,
this would of course screw up the SQL queries. I already have that problem
with the "force_version" entry that sometimes is passed to the _edit() call
(not only edit/ would be affected). This is only a SQL problem, flat_files
and _dba would work fine, even with corrupted $data entries.

Whatever, I'd say it's safer to check against $ewiki_plugins["page"], which
after all wouldn't be that different from an $data['page_plugin'] check -
this would then have been just a move of the if() from your plugin into
ewiki_page(), and thus not really more reliable.

#

RecentChanges: the {author} field now holds the hostname besides IP address
whenever someone edits a page.


Greets,
mario

Other related posts: