ewiki info
READMEChangeLog
project site
fm project page
secondary site
|
$ewiki_plugins["auth_perm"][0] ($id, &$data, $action, $ring, $forcelogin)Is called from within ewiki_auth(), and should return a value of 1 or 0 if permission is granted. The plugin function should determine this by evaluating the current user name. The ["auth_perm"] plugin is itself responsible for retrieving the current username and fetching associated priviliges; but at least the user name can usually be found in the global $ewiki_auth_user or $ewiki_author (previously used therefore) variables. And for the "associated priviliges" the plugin could just concentrate on comparing an already defined $ewiki_ring (which eventually was set by a previously called ["auth_query"] or ["auth_userdb"] plugin) with the currently requested one in the "$ring" parameter. Often an ["auth_perm"] plugin will want to just look at the $action parameter to the currently requested page $id to make its decision (not all users should be allowed all $actions). However often it is easier to first map down the $action/$id parameters to a smaller set of privilige levels (like the 4 ring levels, how the 'auth_perm_ring' plugin does). If a perm plugin however is called with a $ring level request (this is the $ring variable is not NULL or false), then it MUST also take it into account (besides any other calculations on permission granting it already did). The $data parameter contains the internal array of the current WikiPage+ (as usual), and an ["auth_perm"] plugin could of course also use the {meta} field to store access granting informations (the owner name or even a password). Eventually the $data parameter is empty or only requires a few fields; then it may be desirable for the perm plugin to refetch the full database entry via ewiki_database("GET") before anything else. An appropriate check for this case was for example "if (count($data)<=5)". If the ["auth_perm"] plugin detects that access is to be denied, then it should put a failure message into $ewiki_errmsg. One could also write an complete ewiki_auth() replacement using this plugin hook, as all parameters for the original are passed over and only the boolean return value counts. Note: The default ["auth_perm"] plugin ('.../auth_perm_ring.php') only associates those "ring levels" to the different wiki $action tasks, and all real user authentication is done inside "auth_query" - but this is not required, and it's up to your fantasy to do it in a different way (separate login page and auth_perm+ just querying cookies for example).prev << "$ewiki_plugins["auth_perm"][0] ($id, &$data, $action, $ring, $forcelogin)" next >> "$ewiki_plugins["auth_query"][0] (&$data, $login)" You cannot modify the ProtectedMode file, but anyhow any ideas or suggestion should as usually get filed on BugReports, UserSuggestions or even better the ProtectedMode.Discussion. |