Comparison

UserAuth2 was started as reimplementation of the (former) UserAuth module, with the aim of keeping the look-and-feel but removing all the bugs and (for me personally) annoyances of UserAuth. During the implementation I have added some new features (like wildcards) that either seemed plainly necessary or were easy to implement. Find a complete list of changes below. (I would recommend using UserAuth2 (UA2) unless you need the self-registration of users feature, which is currently still missing. There are also some other cookbook recipes (e.g. PresenceAwareness) that rely (currently) on using UserAuth as authentication module.)

A comparison of AuthUser and UserAuth(2) is more difficult, as both are working from a completely different viewpoint on the permission granting. While in AuthUser you will open or restrict access for users or user groups per and by page or group, in UserAuth(2) you will grant access to pages (or page sets defined by pattern) per user. (Page versus user orientation: "By which category is the permission information organized?") In AuthUser you will currently specify this on wiki pages for each page/group, while in UserAuth(2) everything is done over a web admin panel. (More here.)

Changes of UA2 relative to the former UserAuth module

  • removed subsequent pmwiki passwords based authorization (if you are interested in this, vote for it here: )
  • yet missing: user self registration (the userauth-newuser and unserauth-register scripts)
  • yet missing: admin report in the former form
  • new permission file structure => old permission tables can (currently) not be reused; same for passwords, though this can be remedied more easily if necessary.
  • fixes redirection bugs:
    • When jumping directly into some wiki page from extern, the redirection is done correctly after authentication is finished. (This also holds true if the jump is to a action, like edit, of the page.)
    • ... (many others)
  • fixes obliteration of page permissions by group permissions (this was something real BAD)
  • in general all bugs described on UserAuth and UserAuthDevel are fixed, except from the edit loss on session expiration (which will be done as soon as I have digged deeper into this issue) done; posts are now completed after relogin
  • changes in the permission semantics: all clients have at least guest user rights, all users that are logged in have at least logged in user rights; the login page is hardwired always-readable
  • makes negation of abilities possible
  • adds use of wildcards in permission entries
  • adds ip address based silent permission granting
  • adds ip address based login restriction
  • adds delegation capability
  • adds caching of permission results, which make this module faster than the old one (still to be confirmed in practice)
  • improved security:
    • no cleartext passwords anymore in the session array (as a result, the content of written session files could even be public, only the session id itself must be kept secret; of course, now, you have to prevent that someone is writing your session files, since he could attain arbitrary identity)
    • enforces correct expiration of the auth cookie server-sidely
    • same with expiration of sessions themselves (default 2h inactivity, 1 day max life time)
    • uses a random key (instead of (static) password) in the auth cookie
    • session fixation attacks prevented
    • session/client coupling fortified by ip address check, session/site coupling by site identifier check
    • brute force attacks against the login prevented (since version 2.0-stable8)
  • for inner pmwiki use: support of page group permission query ("Has user X access to page group Main.* .")
  • category "favourite annoyances":
    • default input focus on all forms (especially password forms) is set
  • added support for authentication via an LDAP server (since version 2.1-beta2)

It would be really nice if this page (or another?) clearly delineated the differences between AuthUser and UserAuth as well as between UserAuth and UserAuth2. For those of us getting started it would be nice to go to one place and understand briefly what the different approaches are along with advantages/disadvantages... -Peter

Hello Peter, I have tried my best to put up some lines above, but they will be necessarily incomplete as we all have not yet fully understood all advantages/disadvantages of every approach. Feel free to add further points/arguments if you discover. ThomasP June 12, 2007, at 11:18 AM

Hello Thomas, I am very sorry not to realize your efforts lately. I will pay more attention, promissed.
PKHG June 12, at 19:56