[pmwiki-users] AuthUser & FAST Membership - future?
Allister Jenks
arj at zkarj.co.nz
Tue Nov 21 01:35:13 CST 2006
On 11/14/06, The Editor <editor at fast.st> wrote:
> I should add Allister, that from Caveman's perspective FAST Membership
> is already superseded on two levels: 1) by ZAP's CMS capabilities
> which far exceeds it, and 2) by Htpasswdforms which is what FAST
> Membership was hacked off of, but has now been much improved to allow
> new member registration and even group capabilities, so there's no
> real reason for anyone to use FAST Membership. Unless you just like
> the name...
OK, I've had a look at Htpasswordform and it looks to me pretty much
like FM with the added benefit of handling groups. That would be
nice, but I will have to think about ways of converting my
Site.AuthUser page to .htgroups. I also like the auto-logon of a new
user - a problem I had to creatively overcome in my FM implementation
- and sortable files.
I've also checked out ZAP. Wow! What is unclear to me still,
however, is how 'membership' works. What is ZAP actually doing in
this space?
> As for administrative stuff becoming unwieldy, if you can tell me your
> specific problem, I can tell if ZAP can manage it more easily. It can
> sort and list members any way you want to and do any kind of changes
> you wan't to their account very easily. And members can change their
> own profile information so far as you let them.
My basic requirements are (without yet considering the PayPal
integration aspect):
1) Users self register.
2) We manually add new users to 1-4 groups at a time.
3) A new group is created every quarter.
Pretty basic, really. However as things stand with FM, the admin view
is dominated by a large unsorted list of users which, even if sorted,
takes a fair amount of scrolling to either find an entry or just get
past it to the rest of the page. I currently have .htaccess storing
the user info and Site.AuthUser storing the group info. I'm using
standard PmWiki login (not even AuthUser) for admin login.
> As for PayPal, I haven't looked into it much but would like to at some
> point. I'm sure ZAP could be set up to handle it--and I'd be happy to
> set up a ZAP form snippet for you, if you explain the exact format of
> the info PayPal's IPN sends you. A page with a ZAP form could be
> setup to automatically retrieve the GET variables, and even
> self-submit, effecting whatever profile changes (permissions) you
> want. I'm having fun with ZAPchat right at the moment but could be
> distracted momentarily if you were willing to do the PayPal research
> for me.
The trick here is two-fold.
First, you have to accept the relevant PayPal data and respond
correctly to them.
Second (whilst doing the first), you would have to - by some logic I
would need to define - add the current user to one or more groups. We
don't allow non-authenticated users through the PayPal process as we
need to tie the user ID with the PayPal transaction - which we do by
passing the authenticated user ID to PayPal as an 'additional' field.
> Of course, if you are dealing with anything really valuable you might
> want to go with the extra security of a database (ie Crisses
> suggestion). If you want the simplicity of staying all flat files,
> ZAP is the way. Whichever you prefer.
We're talking about modest values for access to online content. The
only reason I would think about using a database is for
stability/robustness. E.g. what happens if our 300 users become
30,000? Does a flat file then fall flat on its face as far as speed
of processing is concerned? Imagine the scrolling with FM!!
--
Allister
More information about the pmwiki-users
mailing list