[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