ewiki info
READMEChangeLog
project site
fm project page
secondary site
|
Your own perm pluginIf you merge ewiki as just one piece into a CMS which already provides user authentication, then you could write a complete ["auth_perm"] plugin as replacement for ewiki_auth() like this: <?php $ewiki_plugins["auth_perm"]0+ = "cms_permissions"; function cms_permissions($id, &$data, $action, $rring, $login) { $user = & $GLOBALS["logged_in_user"]; # if (empty($user)) { $user = CMS_Context+::get_user_from_cookie(); } if (empty($user)) { cms_print_login_form(); } $is_admin = & $GLOBALS["user_is_root"]; $actions_allowed = array( "DEFAULT" => array("view", "links"), "root" => array("edit", "delete", "control", "admin"), "user2" => array("edit", "delete", "info"), "witch" => array("edit", "comment"), "..." => ... ); $ok = in_array($action, $actions_allowed$user+) || in_array($action, $actions_allowed["DEFAULT"]); $ok = $ok || $is_admin; if ($is_admin) { $GLOBALS["ewiki_ring"]=0; } return($ok); } ?> Instead of providing global variables your CMS may allow you to fetch user state/settings via a function or class API. However this plugin shows, how to ignore the $ring level stuff at all (but for the superuser you should set it, because admin/ plugins rely on it).prev << "Your own perm plugin" next >> "No plugin at all" 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. |