Peter Bowers version of self-registration included the concept of creating a new page called AuthUserExtra that is within the SiteAdmin group. The AuthUserExtra page would just supplement information that is included in the AuthUser page. Of course this isn't as "clean" as putting everything in AuthUser, but I personally benefitted from having an AuthUser page that was made only of username and password and an AuthUserExtra page that included all of my fields that were required upon registration.
Thanks, Chris -----Original Message----- From: pmwiki-users-boun...@pmichaud.com [mailto:pmwiki-users-boun...@pmichaud.com] On Behalf Of Eemeli Aro Sent: Thursday, January 22, 2009 11:54 AM To: Patrick R. Michaud Cc: ki...@kirpi.it; PmWiki-Users List Subject: Re: [pmwiki-users] Self registration 2009/1/21 Patrick R. Michaud <pmich...@pobox.com>: > Until I'm able to see a clearly good decision on this latter point -- > that is, until it's clear *where* in PmWiki we will store sensitive > information such as email addresses -- the rest of the discussion is > merely speculation. At least, it's speculation if I'm expected to > support its inclusion in the core. I'd say that anything sensitive needs to go to SiteAdmin.AuthUser or another single location in the SiteAdmin group. This makes tracking changes to it much easier, and helps limit the scope of possible errors. The default admin-only access to these pages require one or more new page actions to be built to access and edit the data, at which point authentication can be verified. If this data is spread eg. all over Profiles group pages verifying that it doesn't get illicitly exposed is much more difficult. I've been working on and off on a recipe for user self-registration, but given complicated organisational reasons making it useless haven't got it in a publishable state yet. My approach was to add the data to SiteAdmin.AuthUser, with extra fields for each user on the line after their username: UserName: hash \ name="" title="" job="" email="" tel="" url="" The non-alphanumeric ' \ ' at the line start lets it be ignored by authuser.php as well as visually tying the info to the preceding UserName declaration, and the subsequent string can be parsed using PmWiki's ParseArgs. This data would then be user-modifiable using a custom PageStore and a page action that'd use a form template to present the info. The accessibility is also customised, such that some fields are only editable by the user themselves, some by all the other members of a specific group the user belongs to (eg. if you're a member of @groupA, other members of @groupA can update your phone number) etc. But as I said, the implementation isn't done yet. If someone's interested, I can send the current version of the code. eemeli _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users