Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-11 Thread Eemeli Aro
2008/7/11 The Editor <[EMAIL PROTECTED]>:
> Actually, ZAP is a pretty simple platform, with a bunch of extension.
> [...] What I've suggested to
> others (for better performance and security both), is to just delete
> or comment out any functions you don't use from the toolbox.

Perhaps, but it's still a generic form processing engine when all I
want is user account administration. And if the toolbox is so modular,
why aren't there 10 different EnableZapToolboxSomething variables that
I could set?

>> Additionally, there are quite a few things that I need that I haven't
>> seen ready solutions for. For example, I want to have
>>  resolve to a default profile page for
>> SomeUser that reads a template from somewhere and SomeUser's data from
>> elsewhere. The tricky part (or at least one of them) is the lack of
>> any default group for these profile pages.
>
> If you could get by with example.com/wiki/Login/SomeUser you could do
> this today in ZAP.

It's actually relatively easy with just the PmWiki core, if you use a
separate group.

> If you can't have the group name (login), surely a line or two in a
> config file could be used to check the page name, and if it matches
> some pattern you simply redirect to the desired page. But using
> Login/SomeUser means you can put a link like [[login.{member}|View
> Profile]] on a page, or the usual ~~.

Can't do the patternmatching since I'm using accounts fo the form
FirstnameLastname which don't provide any common thing to grep for.
And the more difficult part comes from wanting these profile pages
(which I don't want to actually be peppered about the site, but
generated from a single template and a separate data source) to show
up nicely in wiki searches as well as in links; something like
[[FirstnameLastname/|+]] should just work.

The reason for not using a "Users" or "Profiles" group comes from
allowing people to edit their "home pages", which these profile pages
essentially are. As I'm not using a separate group, they can also add
pages under their FirstnameLastname groups and the URLs don't need to
change.

>> Another odd feature that I want is controlled, undoable deletion of
>> other people's user accounts by non-administrators. Most of my sites
>> are internal, and what with the restructuring and changing secretaries
>> and other things, it's not always clear if someone's still an employee
>> or not. And since keeping track of people really isn't my job, I
>> figure I ought to make it possible for anyone to update these details.
>
> This should be a snap in ZAP. Because their login information is
> embedded in their in-wiki login page,anyone with permission can simply
> delete a login page and the password and all data vanishes instantly.
> Plus you don't have to give them access to any critical site pages or
> config files or the like. And if a page were accidently deleted, you
> could always retrieve it like any other deleted PmWiki page as an
> admin.

Perhaps I wan't clear enough. We have admin A and users B and C. User
C leaves and his account should be removed, but no-one remember to. At
some point user B realises this. I want to give him the ability to do
so without requiring admin approval, while maintaining undoability and
not angering user C if B made a mistake.

eemeli

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Vince Administration
Dear Editor,
It might be good to know just what "support" is available for ZAP.
For example: If changes are required to ZAP to have it continue to  
work with later versions of PmWiki or php,  will someone do this?

Vince


On Jul 10, 2008, at 6:59 PM, The Editor wrote:

> On Thu, Jul 10, 2008 at 5:26 PM, Eemeli Aro <[EMAIL PROTECTED]> wrote:
>> 2008/7/10 The Editor <[EMAIL PROTECTED]>:
>>> Though I'm no longer actively supporting ZAP, it's been able to do
>>> this and much more for a long time.
>>
>> I actually did take a look at ZAP and the MemberMgmt recipe before
>> starting, but it's that "and much more" part that turned me away. By
>> now, I know how PmWiki works; I've read through the code enough times
>> to trust what it's doing. Admittedly Pm's code could do with more
>> documentation aimed at developers and longer variable names, but it
>> does all work and lets me pick which parts to enable or disable.
>
> Just thought it might be helpful to have something that is already set
> up for what you are doing. But then again, support these days for ZAP
> is pretty limited.
>
>> ZAP, on the other hand, is a single monolithic recipe that proudly
>> lists 30 different things that it does. The effort I'd need to put
>> into understanding all of it exceeds the effort I'm putting into
>> writing what I need myself. Since we're dealing with account
>> management I figure I need to be extra careful with what I do.
>> Essentially, I don't think I need generic form processing with extra
>> features to enable account administration.
>
> Actually, ZAP is a pretty simple platform, with a bunch of extension.
> The core engine is lean (under 400 lines).  And the toolbox is just a
> collection of standalone modules. And everywhere possible, ZAP taps
> directly into core PmWiki features (from security to page creation to
> whatever, so it works closely with PmWiki). What I've suggested to
> others (for better performance and security both), is to just delete
> or comment out any functions you don't use from the toolbox. If all
> you want is member mgmt features--that means you'ld only need another
> 30 or 40 lines more. Hardly monolithic.
>
>> Additionally, there are quite a few things that I need that I haven't
>> seen ready solutions for. For example, I want to have
>>  resolve to a default profile page for
>> SomeUser that reads a template from somewhere and SomeUser's data  
>> from
>> elsewhere. The tricky part (or at least one of them) is the lack of
>> any default group for these profile pages.
>
> If you could get by with example.com/wiki/Login/SomeUser you could do
> this today in ZAP. I just put a template in the header of the Login
> group and populate it with data saved from their registration form.
> You can even have a form that allows members to edit their profile
> data. As in a button at the bottom if the page name matches their
> member id.  I don't know there is a ready made snippet (probably is),
> but this is the precise purpose ZAP was created for. And I do it all
> the time in BoltWire.
>
> If you can't have the group name (login), surely a line or two in a
> config file could be used to check the page name, and if it matches
> some pattern you simply redirect to the desired page. But using
> Login/SomeUser means you can put a link like [[login.{member}|View
> Profile]] on a page, or the usual ~~.
>
>> Another odd feature that I want is controlled, undoable deletion of
>> other people's user accounts by non-administrators. Most of my sites
>> are internal, and what with the restructuring and changing  
>> secretaries
>> and other things, it's not always clear if someone's still an  
>> employee
>> or not. And since keeping track of people really isn't my job, I
>> figure I ought to make it possible for anyone to update these  
>> details.
>
> This should be a snap in ZAP. Because their login information is
> embedded in their in-wiki login page,anyone with permission can simply
> delete a login page and the password and all data vanishes instantly.
> Plus you don't have to give them access to any critical site pages or
> config files or the like. And if a page were accidently deleted, you
> could always retrieve it like any other deleted PmWiki page as an
> admin.
>
> Anyway, feel free to pursue other options. I'm not pushing ZAP or
> offering to help.
>
> Cheers,
> Dan
>
> ___
> 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


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread The Editor
On Thu, Jul 10, 2008 at 5:26 PM, Eemeli Aro <[EMAIL PROTECTED]> wrote:
> 2008/7/10 The Editor <[EMAIL PROTECTED]>:
>> Though I'm no longer actively supporting ZAP, it's been able to do
>> this and much more for a long time.
>
> I actually did take a look at ZAP and the MemberMgmt recipe before
> starting, but it's that "and much more" part that turned me away. By
> now, I know how PmWiki works; I've read through the code enough times
> to trust what it's doing. Admittedly Pm's code could do with more
> documentation aimed at developers and longer variable names, but it
> does all work and lets me pick which parts to enable or disable.

Just thought it might be helpful to have something that is already set
up for what you are doing. But then again, support these days for ZAP
is pretty limited.

> ZAP, on the other hand, is a single monolithic recipe that proudly
> lists 30 different things that it does. The effort I'd need to put
> into understanding all of it exceeds the effort I'm putting into
> writing what I need myself. Since we're dealing with account
> management I figure I need to be extra careful with what I do.
> Essentially, I don't think I need generic form processing with extra
> features to enable account administration.

Actually, ZAP is a pretty simple platform, with a bunch of extension.
The core engine is lean (under 400 lines).  And the toolbox is just a
collection of standalone modules. And everywhere possible, ZAP taps
directly into core PmWiki features (from security to page creation to
whatever, so it works closely with PmWiki). What I've suggested to
others (for better performance and security both), is to just delete
or comment out any functions you don't use from the toolbox. If all
you want is member mgmt features--that means you'ld only need another
30 or 40 lines more. Hardly monolithic.

> Additionally, there are quite a few things that I need that I haven't
> seen ready solutions for. For example, I want to have
>  resolve to a default profile page for
> SomeUser that reads a template from somewhere and SomeUser's data from
> elsewhere. The tricky part (or at least one of them) is the lack of
> any default group for these profile pages.

If you could get by with example.com/wiki/Login/SomeUser you could do
this today in ZAP. I just put a template in the header of the Login
group and populate it with data saved from their registration form.
You can even have a form that allows members to edit their profile
data. As in a button at the bottom if the page name matches their
member id.  I don't know there is a ready made snippet (probably is),
but this is the precise purpose ZAP was created for. And I do it all
the time in BoltWire.

If you can't have the group name (login), surely a line or two in a
config file could be used to check the page name, and if it matches
some pattern you simply redirect to the desired page. But using
Login/SomeUser means you can put a link like [[login.{member}|View
Profile]] on a page, or the usual ~~.

> Another odd feature that I want is controlled, undoable deletion of
> other people's user accounts by non-administrators. Most of my sites
> are internal, and what with the restructuring and changing secretaries
> and other things, it's not always clear if someone's still an employee
> or not. And since keeping track of people really isn't my job, I
> figure I ought to make it possible for anyone to update these details.

This should be a snap in ZAP. Because their login information is
embedded in their in-wiki login page,anyone with permission can simply
delete a login page and the password and all data vanishes instantly.
Plus you don't have to give them access to any critical site pages or
config files or the like. And if a page were accidently deleted, you
could always retrieve it like any other deleted PmWiki page as an
admin.

Anyway, feel free to pursue other options. I'm not pushing ZAP or
offering to help.

Cheers,
Dan

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Eemeli Aro
2008/7/10 The Editor <[EMAIL PROTECTED]>:
> Though I'm no longer actively supporting ZAP, it's been able to do
> this and much more for a long time.

I actually did take a look at ZAP and the MemberMgmt recipe before
starting, but it's that "and much more" part that turned me away. By
now, I know how PmWiki works; I've read through the code enough times
to trust what it's doing. Admittedly Pm's code could do with more
documentation aimed at developers and longer variable names, but it
does all work and lets me pick which parts to enable or disable.

ZAP, on the other hand, is a single monolithic recipe that proudly
lists 30 different things that it does. The effort I'd need to put
into understanding all of it exceeds the effort I'm putting into
writing what I need myself. Since we're dealing with account
management I figure I need to be extra careful with what I do.
Essentially, I don't think I need generic form processing with extra
features to enable account administration.

Additionally, there are quite a few things that I need that I haven't
seen ready solutions for. For example, I want to have
 resolve to a default profile page for
SomeUser that reads a template from somewhere and SomeUser's data from
elsewhere. The tricky part (or at least one of them) is the lack of
any default group for these profile pages.

Another odd feature that I want is controlled, undoable deletion of
other people's user accounts by non-administrators. Most of my sites
are internal, and what with the restructuring and changing secretaries
and other things, it's not always clear if someone's still an employee
or not. And since keeping track of people really isn't my job, I
figure I ought to make it possible for anyone to update these details.

eemeli

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Vince Admin Account

On Jul 10, 2008, at 11:17 AM, Dominique Faure wrote:

> On Thu, Jul 10, 2008 at 13:20, Vince Administration
>>
>>>


 On Jul 9, 2008, at 4:06 PM, Dominique Faure wrote:

>>
>> Oh, I just remember: there is this recipe to check out:
>> http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
>> It has (amongst many others) this config option:
>>
>> $HtpasswordNewUsers
>>  When set to 1, a new user form is provided to unauthenticated
>> users,
>>  allowing them to register themselves (defaults to 0).
>>
>> This may well be the ticket! and forget all I wrote above about
>> adding users with Fox!
>>
>>
>> ~Hans
>>
>
> I couldn't provide more details :)
>
> --
> Dominique
>


 ___
 pmwiki-users mailing list
 pmwiki-users@pmichaud.com
 http://www.pmichaud.com/mailman/listinfo/pmwiki-users

>>>
>>
>>
>
> Sorry for the late feedback, but I couldn't find enough time to
> correct a minor bug in this code and give you an answer.
>
> The two configuration variables that Hans described previously should
> contains regular PmWiki form markup with some "$Variables" tags
> automatically filled/replaced by the recipe.
>
> You just have to make sure that these tags are defined in your own
> configuration.
>
> --  
> Dominique
Thanks Dominique. I have looked at the php code, but your comments  
above make thinks much clearer.  It is not so
easy to think non-linearly.
  Vince



___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Dominique Faure
On Thu, Jul 10, 2008 at 13:20, Vince Administration
<[EMAIL PROTECTED]> wrote:
> EEmeli,
> Thanks. I have plenty of work to do on the site, so it is no problem to wait
> a week or two.
> And  Hans,
> Thanks,  I see by studying the function I can create a version which will
> collect the data that I  want.
> But I will go slowly because of eemeli's reply. This sounds like what I
> would want to develop in the future as well as now.
>   Vince
>
> On Jul 10, 2008, at 4:27 AM, Eemeli Aro wrote:
>
>> I'm working just now on something that might fill your needs. It's not
>> quite ready yet, but I should be able to get it out by the end of next
>> week (no promises, mind). It's a module on top of authuser that can
>> read and write usernames, password hashes and additional data in
>> SiteAdmin.AuthUser. When done, it'll let me have new users sign up,
>> verify their email addresses and create accounts for them, use email
>> to reset passwords, let users modify additional details, remove users,
>> as well as generate lists of users with specified details.
>>
>> I've actually got most of this already working on my own sites, but I
>> need to polish up the whole lot and finish implementing it as a
>> PageStore extension before I'm ready to publish.
>>
>> In other words, I ought to have a better answer for you next week.
>>
>> eemeli
>>
>> 2008/7/10 Vince Administration <[EMAIL PROTECTED]>:
>>>
>>> Hans, Dominique,
>>> Thanks for pointing me to the htpasswdform recipe. It comes very
>>> close to what I want.  The only thing that I really can't quite
>>> figure out how to
>>> do is to modify the login form, since it is created by a PHP
>>> program.   I don't want to give exact details of what I want the form
>>> to collect because
>>> then you might do it for me, and it is probably not of wide interest.
>>> But is there a reasonable way to use a custom form for new users?
>>> I guess by reasonable I mean without writing the php code.  I see
>>> that there are a lot of SDV's, so that it might be possible to
>>> customize.
>>>
>>> Thanks for your help.
>>>   Vince
>>>
>>> On Jul 9, 2008, at 4:06 PM, Dominique Faure wrote:
>>>
 On Wed, Jul 9, 2008 at 20:56, Hans <[EMAIL PROTECTED]> wrote:
>
> Wednesday, July 9, 2008, 3:54:22 PM, Vince Administration wrote:
>
>>  The idea is to have read access to anyone,  but
>> posting only for authenticated users.  For a start I would like the
>> users to authenticate themselves by filling in a form.
>
> Not sure how this can be done. The standard way for granting users
> some authorisation in PmWiki would be to install PmWiki.AuthUser
> and add user id's to SiteAdmin.AuthUser.
>
> Fox or FoxForum has no separate user management. It is perceivable
> that Fox could be used to add userid/password pairs to
> SiteAdmin.AuthUser. But that alone will not grant any access rights.
> The userid needs to be added to a @group as well. Fox could do that
> too I guess. And then that user group, say call it @forummembers, can
> be used as id for an edit password for the Forum wiki group,
> and you set for that Forum group  $FoxAuth = 'edit';
>
> Of course the initial NewForumMember form needs to be able/allowed to
> post (add) to SiteAdmin.AuthUser.
>
> This may work (not tried any of this), but as soon as we let users
> add themselves plus password to SiteAdmin.AuthUser we have the
> problem
> to check first if the userid does already exist. And most likely
> users would like to be able to change their password. I don't see any
> simple solution there.
>
> Oh, I just remember: there is this recipe to check out:
> http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
> It has (amongst many others) this config option:
>
> $HtpasswordNewUsers
>   When set to 1, a new user form is provided to unauthenticated
> users,
>   allowing them to register themselves (defaults to 0).
>
> This may well be the ticket! and forget all I wrote above about
> adding users with Fox!
>
>
>  ~Hans
>

 I couldn't provide more details :)

 --
 Dominique

>>>
>>>
>>> ___
>>> pmwiki-users mailing list
>>> pmwiki-users@pmichaud.com
>>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>>>
>>
>
>

Sorry for the late feedback, but I couldn't find enough time to
correct a minor bug in this code and give you an answer.

The two configuration variables that Hans described previously should
contains regular PmWiki form markup with some "$Variables" tags
automatically filled/replaced by the recipe.

You just have to make sure that these tags are defined in your own
configuration.

-- 
Dominique

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread The Editor
On Thu, Jul 10, 2008 at 7:20 AM, Vince Administration
<[EMAIL PROTECTED]> wrote:
> EEmeli,
> Thanks. I have plenty of work to do on the site, so it is no problem
> to wait a week or two.
> And  Hans,
> Thanks,  I see by studying the function I can create a version which
> will collect the data that I  want.
> But I will go slowly because of eemeli's reply. This sounds like what
> I would want to develop in the future as well as now.
>Vince


Though I'm no longer actively supporting ZAP, it's been able to do
this and much more for a long time. I particularly like it because you
can set up a complete user profile with any settings you want for each
user, and then do site customizations or reports of about anything you
want.  It also has easy, advanced group managment. And with a little
work you can set up email verification systems, password reminders,
password change forms, etc.Plus you can also do it all in wiki markup
without having to touch php.

See this recipe

http://www.pmwiki.org/wiki/Cookbook/MemberMgmt

I've incorporated these concepts into the core of the wiki I'm using
now (BoltWire) and I use them all the time. ZAP can give similar
member mgmt capabilities to PmWiki.

Cheers,
Dan

___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Vince Administration
EEmeli,
Thanks. I have plenty of work to do on the site, so it is no problem  
to wait a week or two.
And  Hans,
Thanks,  I see by studying the function I can create a version which  
will collect the data that I  want.
But I will go slowly because of eemeli's reply. This sounds like what  
I would want to develop in the future as well as now.
Vince

On Jul 10, 2008, at 4:27 AM, Eemeli Aro wrote:

> I'm working just now on something that might fill your needs. It's not
> quite ready yet, but I should be able to get it out by the end of next
> week (no promises, mind). It's a module on top of authuser that can
> read and write usernames, password hashes and additional data in
> SiteAdmin.AuthUser. When done, it'll let me have new users sign up,
> verify their email addresses and create accounts for them, use email
> to reset passwords, let users modify additional details, remove users,
> as well as generate lists of users with specified details.
>
> I've actually got most of this already working on my own sites, but I
> need to polish up the whole lot and finish implementing it as a
> PageStore extension before I'm ready to publish.
>
> In other words, I ought to have a better answer for you next week.
>
> eemeli
>
> 2008/7/10 Vince Administration <[EMAIL PROTECTED]>:
>> Hans, Dominique,
>> Thanks for pointing me to the htpasswdform recipe. It comes very
>> close to what I want.  The only thing that I really can't quite
>> figure out how to
>> do is to modify the login form, since it is created by a PHP
>> program.   I don't want to give exact details of what I want the form
>> to collect because
>> then you might do it for me, and it is probably not of wide interest.
>> But is there a reasonable way to use a custom form for new users?
>> I guess by reasonable I mean without writing the php code.  I see
>> that there are a lot of SDV's, so that it might be possible to
>> customize.
>>
>> Thanks for your help.
>>Vince
>>
>> On Jul 9, 2008, at 4:06 PM, Dominique Faure wrote:
>>
>>> On Wed, Jul 9, 2008 at 20:56, Hans <[EMAIL PROTECTED]> wrote:

 Wednesday, July 9, 2008, 3:54:22 PM, Vince Administration wrote:

>  The idea is to have read access to anyone,  but
> posting only for authenticated users.  For a start I would like  
> the
> users to authenticate themselves by filling in a form.

 Not sure how this can be done. The standard way for granting users
 some authorisation in PmWiki would be to install PmWiki.AuthUser
 and add user id's to SiteAdmin.AuthUser.

 Fox or FoxForum has no separate user management. It is perceivable
 that Fox could be used to add userid/password pairs to
 SiteAdmin.AuthUser. But that alone will not grant any access  
 rights.
 The userid needs to be added to a @group as well. Fox could do that
 too I guess. And then that user group, say call it  
 @forummembers, can
 be used as id for an edit password for the Forum wiki group,
 and you set for that Forum group  $FoxAuth = 'edit';

 Of course the initial NewForumMember form needs to be able/ 
 allowed to
 post (add) to SiteAdmin.AuthUser.

 This may work (not tried any of this), but as soon as we let users
 add themselves plus password to SiteAdmin.AuthUser we have the
 problem
 to check first if the userid does already exist. And most likely
 users would like to be able to change their password. I don't  
 see any
 simple solution there.

 Oh, I just remember: there is this recipe to check out:
 http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
 It has (amongst many others) this config option:

 $HtpasswordNewUsers
When set to 1, a new user form is provided to unauthenticated
 users,
allowing them to register themselves (defaults to 0).

 This may well be the ticket! and forget all I wrote above about
 adding users with Fox!


  ~Hans

>>>
>>> I couldn't provide more details :)
>>>
>>> --
>>> Dominique
>>>
>>
>>
>> ___
>> 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


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Eemeli Aro
I'm working just now on something that might fill your needs. It's not
quite ready yet, but I should be able to get it out by the end of next
week (no promises, mind). It's a module on top of authuser that can
read and write usernames, password hashes and additional data in
SiteAdmin.AuthUser. When done, it'll let me have new users sign up,
verify their email addresses and create accounts for them, use email
to reset passwords, let users modify additional details, remove users,
as well as generate lists of users with specified details.

I've actually got most of this already working on my own sites, but I
need to polish up the whole lot and finish implementing it as a
PageStore extension before I'm ready to publish.

In other words, I ought to have a better answer for you next week.

eemeli

2008/7/10 Vince Administration <[EMAIL PROTECTED]>:
> Hans, Dominique,
> Thanks for pointing me to the htpasswdform recipe. It comes very
> close to what I want.  The only thing that I really can't quite
> figure out how to
> do is to modify the login form, since it is created by a PHP
> program.   I don't want to give exact details of what I want the form
> to collect because
> then you might do it for me, and it is probably not of wide interest.
> But is there a reasonable way to use a custom form for new users?
> I guess by reasonable I mean without writing the php code.  I see
> that there are a lot of SDV's, so that it might be possible to
> customize.
>
> Thanks for your help.
>Vince
>
> On Jul 9, 2008, at 4:06 PM, Dominique Faure wrote:
>
>> On Wed, Jul 9, 2008 at 20:56, Hans <[EMAIL PROTECTED]> wrote:
>>>
>>> Wednesday, July 9, 2008, 3:54:22 PM, Vince Administration wrote:
>>>
  The idea is to have read access to anyone,  but
 posting only for authenticated users.  For a start I would like the
 users to authenticate themselves by filling in a form.
>>>
>>> Not sure how this can be done. The standard way for granting users
>>> some authorisation in PmWiki would be to install PmWiki.AuthUser
>>> and add user id's to SiteAdmin.AuthUser.
>>>
>>> Fox or FoxForum has no separate user management. It is perceivable
>>> that Fox could be used to add userid/password pairs to
>>> SiteAdmin.AuthUser. But that alone will not grant any access rights.
>>> The userid needs to be added to a @group as well. Fox could do that
>>> too I guess. And then that user group, say call it @forummembers, can
>>> be used as id for an edit password for the Forum wiki group,
>>> and you set for that Forum group  $FoxAuth = 'edit';
>>>
>>> Of course the initial NewForumMember form needs to be able/allowed to
>>> post (add) to SiteAdmin.AuthUser.
>>>
>>> This may work (not tried any of this), but as soon as we let users
>>> add themselves plus password to SiteAdmin.AuthUser we have the
>>> problem
>>> to check first if the userid does already exist. And most likely
>>> users would like to be able to change their password. I don't see any
>>> simple solution there.
>>>
>>> Oh, I just remember: there is this recipe to check out:
>>> http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
>>> It has (amongst many others) this config option:
>>>
>>> $HtpasswordNewUsers
>>>When set to 1, a new user form is provided to unauthenticated
>>> users,
>>>allowing them to register themselves (defaults to 0).
>>>
>>> This may well be the ticket! and forget all I wrote above about
>>> adding users with Fox!
>>>
>>>
>>>  ~Hans
>>>
>>
>> I couldn't provide more details :)
>>
>> --
>> Dominique
>>
>
>
> ___
> 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


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-10 Thread Hans
Thursday, July 10, 2008, 12:43:09 AM, Vince Administration wrote:

> But is there a reasonable way to use a custom form for new users?
> I guess by reasonable I mean without writing the php code.  I see  
> that there are a lot of SDV's, so that it might be possible to  
> customize.

you find in the script a section starting with
  SDV($HtpasswordForms['user']
and another with
  SDV($HtpasswordForms['new']

you can see that each defines a PmWiki form, using PmWiki input
markup etc. which may be familiar with. The \n simple create line
breaks for conveniance.

Both are set as SDVs, so you can define your own in config.php,
before including the script:

$HtpasswordForms['user'] = "

.your PmWiki user form markup.

";

$HtpasswordForms['new'] = "

.your PmWiki new user form markup.

";

Make sure you got all the field elements in it, and add what you need.
Use normal wiki markup. Use \n only for convenient linebreaks (it is
used to make the code look a bit more compact). No other php
necessary.

Hope that helps!


  ~Hans


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users


Re: [pmwiki-users] Semi-automatic user accounts for fox forum -- Htpasswdform

2008-07-09 Thread Vince Administration
Hans, Dominique,
Thanks for pointing me to the htpasswdform recipe. It comes very  
close to what I want.  The only thing that I really can't quite  
figure out how to
do is to modify the login form, since it is created by a PHP  
program.   I don't want to give exact details of what I want the form  
to collect because
then you might do it for me, and it is probably not of wide interest.  
But is there a reasonable way to use a custom form for new users?
I guess by reasonable I mean without writing the php code.  I see  
that there are a lot of SDV's, so that it might be possible to  
customize.

Thanks for your help.
Vince

On Jul 9, 2008, at 4:06 PM, Dominique Faure wrote:

> On Wed, Jul 9, 2008 at 20:56, Hans <[EMAIL PROTECTED]> wrote:
>>
>> Wednesday, July 9, 2008, 3:54:22 PM, Vince Administration wrote:
>>
>>>  The idea is to have read access to anyone,  but
>>> posting only for authenticated users.  For a start I would like the
>>> users to authenticate themselves by filling in a form.
>>
>> Not sure how this can be done. The standard way for granting users
>> some authorisation in PmWiki would be to install PmWiki.AuthUser
>> and add user id's to SiteAdmin.AuthUser.
>>
>> Fox or FoxForum has no separate user management. It is perceivable
>> that Fox could be used to add userid/password pairs to
>> SiteAdmin.AuthUser. But that alone will not grant any access rights.
>> The userid needs to be added to a @group as well. Fox could do that
>> too I guess. And then that user group, say call it @forummembers, can
>> be used as id for an edit password for the Forum wiki group,
>> and you set for that Forum group  $FoxAuth = 'edit';
>>
>> Of course the initial NewForumMember form needs to be able/allowed to
>> post (add) to SiteAdmin.AuthUser.
>>
>> This may work (not tried any of this), but as soon as we let users
>> add themselves plus password to SiteAdmin.AuthUser we have the  
>> problem
>> to check first if the userid does already exist. And most likely
>> users would like to be able to change their password. I don't see any
>> simple solution there.
>>
>> Oh, I just remember: there is this recipe to check out:
>> http://www.pmwiki.org/wiki/Cookbook/HtpasswdForm
>> It has (amongst many others) this config option:
>>
>> $HtpasswordNewUsers
>>When set to 1, a new user form is provided to unauthenticated  
>> users,
>>allowing them to register themselves (defaults to 0).
>>
>> This may well be the ticket! and forget all I wrote above about
>> adding users with Fox!
>>
>>
>>  ~Hans
>>
>
> I couldn't provide more details :)
>
> --
> Dominique
>


___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users