ewiki_auth() calls

• SHOULD
  • respect the overall _PROTECTED_MODE setting (because the ProtectedMode is a highly optional ewiki feature)
  • pass the $data and $action whenever available
  • return $ewiki_errmsg strings on failure (or a custom message)

auth_perm plugins

• MUST
  • be thread-safe ;)
  • return error html strings only via $ewiki_errmsg
• SHOULD
  • respect the requested ring level (admin, moderator, editor, guest)
  • refetch the database entry for $id, if they require the full $data entry, but this was empty or incomplete - the appropriate check for this was if(count($data)<7)
  • ...
  • ...
  • ...
  • use auth_query plugins and ewiki_auth_user()
• MAY
  • incorporate the authentication challenge (which otherwise would be handled by the auth_query plugins)
  • also intermix with a user database then
  • be a complete ewiki_auth() replacement
  • completely ignore all rules defined herein, and provide a really extravagant permission granting system - eventual incompatibilites must then be noted, and other plugins should not provide workarounds for it then
  • mangle $data if this adds security

auth_query

• SHOULD
  • be prepared to be itself an interception in POST queries (and MUST handle it transparently)

userdb

• SHOULD
  • return an array() with $pw,$ring_level,$AuthorName as elements (everything else would be ignored) - the password then being compared by the ewiki_auth_user() function
• MAY
  • do authentication remotely, without knowing or reporting (in the mentioned array structure) the real password