[pmwiki-users] AuthUser & FAST Membership - future?

The Editor editor at fast.st
Tue Nov 21 05:11:21 CST 2006


On 11/21/06, Allister Jenks <arj at zkarj.co.nz> wrote:
> 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.

Actually FAST Membership was just a hack of Htpasswdform, when it
didn't allow users to create their own accounts.  It was the original.
 Mine was the derivative.

> 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?

You use a simple ZAP form to create a member profile with any fields
you want: realname, email, phone, whatever.  Two required fields are
Member and Password.  The info is all stored in Profiles.Member (or
you can change to another group for added security if you wish).  When
someone log's in the Member name and Password they enter are checked
against the appropriate Profile page.  If the passwords match, they
authenticate them as that user.  All of this can be seen in action at
ZAP.  Works like a charm.

> > 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.

Also this is easy with ZAP.  Because of how flexible ZAP is you can do
anything you want on a registration form.  Email yourself the data,
create new pages, send a welcome email, verify their email first,
whatever.  The way I do the list of members in the ZAP chat rooms is
simply create a page like Chat-Room-Name.AuthId, and then do a
pagelist of everyone in the group.  ZAP can also delete such pages at
the click of a button.  To see if someone is in a group, just do (:if
exists Group.AuthId:)...  Very easy to work with.

Another approach is to use ZAP's list features, where each group has a
csv list of members.  With listing, members can be added and dropped
easily, the entire list can be sent emails (drawn from their profiles
pages), or whatever.  ZAP also has an "inlist" conditional which can
tell whether someone is in a list very easily.

ZAP takes a bit to get the hang of it, but it really  makes a lot of
advanced functions quite easy.

> 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.

Not only can you pull up just a list of members in a group, you could
use text vars in your pagelist to only pull up members in group x if
their profiles page indicates they are in state y.  And of course you
could make each link go to their profiles page which is set up that if
you are admin, you can automatically update any of the pages.
Whatever you want to do.

> > 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.

Yes, I have an idea how it works.  If you could tell me exactly what
info PayPal sends you (how it is formatted, etc.  I'm assuming its a
GET/POST string with specific fields...) I can set up a form to
retrieve that information and process it.  ZAP can already read GET
values, and I already have a nifty little trick for auto submitting
forms (might be able to get it to read incoming POST values).  So you
just create a ZAP form, prepopulate it with the PayPal information and
send it.  If you have their user ID, it's a snap to add them to your
groups. I'd be happy to help, as I think it's a useful feature for ZAP
to make available.

> > 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!!

I've been told the newer server OS's all automatically index pages in
their groups, so the performance difference should be minimal between
a big bunch of flat files and a big database table.  Others on the
list who know more about these things will have to chime in on this
question.

Cheers,
Caveman




More information about the pmwiki-users mailing list