KnownIssues

This is for the Cookbook.UserAuth2 module.

Known Issues

  • Admin report not yet implemented.
  • Profiles not implemented
    (Might be done in another way than planned: have rather pages of form MySettings.Max that are editable only by Max, and put on there the options of the user, for example in form of well-formated code sections that are read whenever some setting is needed, e.g. notification. => very flexible). Using Cookbook.MemberMgmt might be a still better way.
  • Not yet tested in a SSL environment. Charles has put some hints derived from his configuration already at UserAuth2-Talk. The redirection definitions will surely sooner or later be incorporated directly into the userauth2.php code (for simplicity).
  • The set of allowed characters in page names is very restricted at the moment (see ImplementationReference, "valid characters", for details). This might be relaxed appropriately as need arises.
  • If you want to use {$AuthId} to grant personal permissions it will be necessary to use usernames containing letters and digits only (i.e. no underscore).
  • Even with correct usernames it seems {$AuthId} is not supported in grant permission Felie see below
  • Recently appeared: redirection after login on explicitly specifying a target which needs privileges is not working at my place. (Also the messages "Authentication required does not appear in this case, so obviously the SESSION variables are not correctly loaded in this case.) To be investigated. ThomasP April 18, 2007, at 06:34 AM. Keeps changing, so seems to be a PHP internal cause, or session cookie not transmitted/available directly after redirection?
  • There is a slight chance that, when browsing with multiple tabs, a session file deadlock occurs. The reason is that session_write_close() is not employed as would be done in the engine.

Todo

  • revisit localization
  • revisit CSS usage: is every output customizable via CSS file?
  • better integration with / adaption to the usual pmwiki authentication code:
    For example, having the auth form as a wiki page would be nice. (This is currently highly unconfigurable code.) Besides, some parts of the redirection logic can maybe let done by the engine (and auth messages, PostVars etc.). This would be much better in case of engine upgrades.

    Besides integration with other authentication modules, like AuthUserDB, MemberMgmt, Htpasswd recipes. Please tell me if there is a functionality you'd like especially to be included. (see http://article.gmane.org/gmane.comp.web.wiki.pmwiki.user/43069 also)

Missing features (at the moment) / Wishlist

  • alternative authentication channels (.htpasswd, etc.)
    (Will be done as soon it is needed by someone. Idea is to directly ride the functions around $AuthUserId in script/authuser.php.)
  • permission test query form (e.g. with an inline frame)
  • support for a large number of users (around 1000)
    (Since the permission evaluation engine itself is well prepared for this, all remains to do is to implement partial user lists in the admin tool.)
  • Feature to support Inline Frame (What exactly is meant with this? ThomasP July 10, 2008, at 10:14 AM)
  • User self registration

Remaining security focus

How does the insecurity of PHP-set variables (_SERVER[SCRIPT_URL] etc.) affect the security of this module?


rd_*.*,
ed_Main.*,
up_Main.*,
hi_Main.*,
-ed_*.SideBar,
pw,
-ad,
-ed_Ai.*,
-ed_Perso*.*,
ed_Perso{$AuthId}.*,
rd_Perso{$AuthId}.*,
up_Perso{$AuthId}.*,
hi_Perso{$AuthId}.*,
-ed_Main.PagesPerso,
ed_Perso.{$AuthId},
up_Perso.{$AuthId},
hi_Perso.{$AuthId}

and user Toto can't edit his page Perso/Toto ??? Felie