Re: [pmwiki-users] A robust user registration module

[Peter Bowers]

On Sat, May 29, 2010 at 11:33 AM, Wordit Ltd  wrote:
> On Fri, May 28, 2010 at 2:30 PM, Eemeli Aro  wrote:
>>
>> I'm working on the next version of that just now, a rather heavy-duty 
>> refactoring of the code to make it more generic, separating the back-end 
>> storage solution from the rest of the code.
>
> Sounds like a good plan. I think this particular recipe needs a sort
> of open API functionality, so that other recipes can call upon it
> rather than authors having to create new versions of the sign-up
> recipe to suit each type of usage.
>
>... once backend storage is
> separate, it is easy for another recipe to specify a temp storage
> page, and copy data over after verification.

Ideally it may be nice to have temp storage (for registered but
unconfirmed users) as a separate plug-in from the back-end storage.
For instance, if someone wants Profile.X as their back-end storage
they may not want lots of unused Profile.X pages for people that don't
every get far enough to verify/confirm their registration...  That
would also simplify (albeit slightly) the job of writing the back-end
storage plug-in.

-Peter

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

On Fri, May 28, 2010 at 2:30 PM, Eemeli Aro  wrote:
>
> I'm working on the next version of that just now, a rather heavy-duty 
> refactoring of the code to make it more generic, separating the back-end 
> storage solution from the rest of the code.


Sounds like a good plan. I think this particular recipe needs a sort
of open API functionality, so that other recipes can call upon it
rather than authors having to create new versions of the sign-up
recipe to suit each type of usage.


@Dave, I also think captcha should suffice.
If captcha is not an option for someone, then once backend storage is
separate, it is easy for another recipe to specify a temp storage
page, and copy data over after verification.


Marcus

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

Re: [pmwiki-users] A robust user registration module

[Simon]

Using captcha or textcaptcha
may be helpful here

On 29 May 2010 02:48, DaveG  wrote:

>
>
> On 5/28/2010 6:35 AM, Eemeli Aro wrote:
>
>> On 27 May 2010 17:16, Wordit Ltd  wrote:
>>
>>> - The data does not have to be stored *before* verification because
>>> the data will be sent back when the user clicks the email link, and
>>> the key tells us if it's correct.
>>>
>>
>> The way I see it, storing the new user data on first submission is a
>> relatively easy task, no matter what background storage system is
>> used.
>>
> We'd need some way to manage the likely spam signups. Perhaps placing the
> 'pending verification' data in a separate page would suffice.
>
>  ~ ~ Dave
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] A robust user registration module

[DaveG]

On 5/28/2010 6:35 AM, Eemeli Aro wrote:

On 27 May 2010 17:16, Wordit Ltd  wrote:

- The data does not have to be stored *before* verification because
the data will be sent back when the user clicks the email link, and
the key tells us if it's correct.


The way I see it, storing the new user data on first submission is a
relatively easy task, no matter what background storage system is
used.
We'd need some way to manage the likely spam signups. Perhaps placing 
the 'pending verification' data in a separate page would suffice.


 ~ ~ Dave

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

Re: [pmwiki-users] A robust user registration module

[Eemeli Aro]

On 28 May 2010 15:24, Wordit Ltd  wrote:
> Eemeli, you already have the mechanisms in your new AuthUserProfiles
> recipe proposal. Why not have an email-only option, stored in a
> separate place for these purposes?
>
> e.g. SiteAdmin.VerifiedAddresses, or whatever, which other recipes can
> access. Unsubscribing can use the same mechanism as the
> subscription/sign-up process.

I'm working on the next version of that just now, a rather heavy-duty
refactoring of the code to make it more generic, separating the
back-end storage solution from the rest of the code. I'll publish a
new version once it's got at least the features that the current
AuthUserProfiles has.

eemeli

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

On Fri, May 28, 2010 at 12:35 PM, Eemeli Aro  wrote:
>
> There are at least three benefits from storing the data, as opposed to 
> passing it through the authentication link...


There certainly are benefits, and I did use a temp sign-up storage
file myself. I was just suggesting a solution with less work since
initially everybody said they had little to no time to work on this
recipe.

There are other benefits to storing sign-up data, which I also used.
Store the IP and you can limit attempts to crack the secret. Store the
date to have the link expire, etc.


> For using PmWiki data as a back-end to a newsletter or mailing list, I'd 
> recommend Enemies of Carlotta:


I was thinking of Notify/FoxNotify, and other pmwiki based mailing recipes.

Eemeli, you already have the mechanisms in your new AuthUserProfiles
recipe proposal. Why not have an email-only option, stored in a
separate place for these purposes?

e.g. SiteAdmin.VerifiedAddresses, or whatever, which other recipes can
access. Unsubscribing can use the same mechanism as the
subscription/sign-up process.


Marcus

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

Re: [pmwiki-users] A robust user registration module

[Eemeli Aro]

On 27 May 2010 17:16, Wordit Ltd  wrote:
> - The data does not have to be stored *before* verification because
> the data will be sent back when the user clicks the email link, and
> the key tells us if it's correct.

The way I see it, storing the new user data on first submission is a
relatively easy task, no matter what background storage system is
used. As a minimum, each of those will need to store the password hash
somewhere, and it's easy to "corrupt" it by combining it with the key
(in an identifiable reversible manner, of course).

There are at least three benefits from storing the data, as opposed to
passing it through the authentication link:

1) Query parameters will get stored into browser histories and other
places; we'll be leaking personal information jsut for our own minor
convenience

2) Authentication links get significantly longer, which may produce
more copy-paste errors, especially if an e-mail client breaks the link
to multiple lines

3) There's a secret that is potentially discoverable and would allow
bypassing the authentication. Minor risk (salted MD5 hash...) and with
little reward, but still...

> - This also works for email subscription only sign-ups to newsletters
> or Notify, for users without accounts. It should not require a
> username and password.

For using PmWiki data as a back-end to a newsletter or mailing list,
I'd recommend Enemies of Carlotta
. It's no longer maintained, but
the latest version seems stable. The reason I recommend it is that it
has very few external requirements, and its back-end is completely
flat-file. This means that it's been relatively simple to write a
function for $EditFunctions that uses a pagelist to get the e-mail
addresses, and writes the changes to the EoC subscriber lists.

If someone's interested, I can publish the code, but I figured it's a
bit too arcane for general use. I'm also using MHonArc
 to convert the list archives to HTML, and
yet more custom code to make that accessible from within PmWiki
(including attachments, which TBH I was surprised would work).

eemeli

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

Re: [pmwiki-users] A robust user registration module

[DaveG]

On 5/26/2010 1:30 AM, Eemeli Aro wrote:

On 26 May 2010 02:03, DaveG  wrote:

On 5/25/2010 12:35 AM, V.Krishn wrote:

Somehow I think sha1($email.$username.$password) should be sufficient.
Secondly,
As no user info(including email) is stored on server,
what would be the method to resend new password when lost?


You would never resend a password, but would rather reset it. So if the
email address is not stored, then basically follow the same process as
initial sign up.

Note, I'm not suggesting there is no need to store email. Simply
highlighting it's not needed for password resets.


Ummm, how exactly? If the server only keeps the username and password
hash, how do you verify that the email address a password reset is
sent to is that user's email address? How do you prevent an account
being highjacked just by knowing the username?
What I meant to highlight was it's not necessary to use a stored email 
for a password reset -- thus the reset process could be the same as the 
registration process.


As you point out the email/password combo does need to be stored 
somewhere in order to actually authenticate.


 ~ ~ Dave

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

In reply to various issues above.

- The user clicks on a link, a "GET" query string. They do not have to
re-enter information.

- The data does not have to be stored *before* verification because
the data will be sent back when the user clicks the email link, and
the key tells us if it's correct.

- Upon successful verification the email and any other data has been
stored, so you have the data to unsub an email address. Just look it
up by supplying the storage page.

- This also works for email subscription only sign-ups to newsletters
or Notify, for users without accounts. It should not require a
username and password.

- Unsubscribing uses the same mechanism. The email is again hashed
with a secret. The user clicks the link, the key is checked, voila!,
verified or not.

- You can verify any info like this. It is not only against spammers,
but also hijacking. Only the real user has access to their email
account.That is the second reason for sending emails.

- The sign-up system could allow the admin, or other cookbooks, full
control. They specify which fields, only email is mandatory.
They specify where to write the verified data, and the separator.

fields: email, user, password
storagePage: SiteAdmin.Whatever
separator: ','

Marcus

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

Re: [pmwiki-users] A robust user registration module

[Oliver Betz]

DaveG wrote:

>> One of the most useful things you can do with a verified e-mail
>> address that's linked to a user account is to use it to reset a
>> password. With the above method, where is the email address kept? If
>> you immediately forget the e-mail address, why do you verify it in the
>> first place?
>I don't totally agree with this. A password reset could be approached 
>using the same mechanism that was used for an initial register.

how do yo prevent that someone "hijacks" an account?

The (stored) e-mail address is an independent authentication method.

Without this, "forgot password" is a PITA for the admin.

Besides this, I'm happy with HtpasswdForm.

Oliver


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

Re: [pmwiki-users] A robust user registration module

[Eemeli Aro]

On 26 May 2010 02:03, DaveG  wrote:
> On 5/25/2010 12:35 AM, V.Krishn wrote:
>> Somehow I think sha1($email.$username.$password) should be sufficient.
>> Secondly,
>> As no user info(including email) is stored on server,
>> what would be the method to resend new password when lost?
>
> You would never resend a password, but would rather reset it. So if the
> email address is not stored, then basically follow the same process as
> initial sign up.
>
> Note, I'm not suggesting there is no need to store email. Simply
> highlighting it's not needed for password resets.

Ummm, how exactly? If the server only keeps the username and password
hash, how do you verify that the email address a password reset is
sent to is that user's email address? How do you prevent an account
being highjacked just by knowing the username?

eemeli

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

Re: [pmwiki-users] A robust user registration module

[DaveG]

On 5/25/2010 3:59 AM, Eemeli Aro wrote:

The only general functions needed are to find a line in a wiki page,
and write to a page. (I guess both these already exist as pmwiki
functions?)


One of the most useful things you can do with a verified e-mail
address that's linked to a user account is to use it to reset a
password. With the above method, where is the email address kept? If
you immediately forget the e-mail address, why do you verify it in the
first place?
I don't totally agree with this. A password reset could be approached 
using the same mechanism that was used for an initial register.


You verify the email address mainly to prevent spam sign-ups. Personally 
I'd also vote for using the email address as the username. That was we 
don't have to validate for uniqueness. However, this would mean we 
couldn't create profile pages based on 'username', since I don't think 
the patterns for valid email addresses is the same as for valid pagenames.




Requiring the user to enter their email address once before and then
again after activation seems silly. What's the harm in keeping the
info on the server if it makes a user's first experience with the site
easier?
Having the option to store the email is the way to go. However, is it 
possible that there might be some country specific regulatory issues 
with storing emails? I don't know, just asking.



 ~ ~ Dave

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

Re: [pmwiki-users] A robust user registration module

[DaveG]

On 5/25/2010 12:35 AM, V.Krishn wrote:

Somehow I think sha1($email.$username.$password) should be sufficient.
Secondly,
As no user info(including email) is stored on server,
what would be the method to resend new password when lost?
You would never resend a password, but would rather reset it. So if the 
email address is not stored, then basically follow the same process as 
initial sign up.


Note, I'm not suggesting there is no need to store email. Simply 
highlighting it's not needed for password resets.



 ~ ~ Dave

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

Re: [pmwiki-users] A robust user registration module

[Eemeli Aro]

On 24 May 2010 13:59, Wordit Ltd  wrote:
> I just realised this a lot simpler than I thought. There is no need
> for temporarily storing the sign-up info.
>
> I think this should work:
>
> - user supplies email, username, password via a form
>
> - create a key containing supplied info plus a secret: sha1($email.).
>
> - Mail to user. No record is kept because the key can be generated
> from info the returning user enters plus the secret.
>
> - user goes to verification page and enters the info plus the key. The
> key is checked.
>
> - if it matches, append, replace, or remove entry in wiki page
>
> The only general functions needed are to find a line in a wiki page,
> and write to a page. (I guess both these already exist as pmwiki
> functions?)

One of the most useful things you can do with a verified e-mail
address that's linked to a user account is to use it to reset a
password. With the above method, where is the email address kept? If
you immediately forget the e-mail address, why do you verify it in the
first place?

Requiring the user to enter their email address once before and then
again after activation seems silly. What's the harm in keeping the
info on the server if it makes a user's first experience with the site
easier?

If two users both want to register the same username, the one that
first activates it gets it, rather than the one that first requests
it, which is a more common way of doing it.

Requiring an admin to come up with a secret for the hash adds extra
work that isn't necessary, and you can't set any default values for
it. For both the user and the admin, it's easier if the information is
kept on the server, and the key to be a randomly generated string that
can be matched to the information.

Is the number of non-activated accounts really going to be big enough
that you need to care about them polluting the namespace? To weed out
spammers, a captcha and a honeypot field should be sufficient.

If you don't care about keeping the email address, or if you want to
put it somewhere less accessible like the page change summary, I'd
implement this as follows:
  1. Get $username, $password, $email from user + validate them
  2. Generate $hash from $password
  3. Generete $key from random number generator
  4. Set $ChangeSummary to something like "added $username <$email>"
  5. Add a line to SiteAdmin.AuthUser:
  #$key $username: $hash
  6. Send $key to user as activation link in an email
  7. Tell user to click on activation link
  8. On activation, find the line matching the key
  9. Remove "#$key " from the beginning of the line
  10. Done.

Now, most of the work will go into the framework for doing all that
along with the input validation. The code for actually reading &
writing pages is actually a small part of the whole. For a practical
example of this, see the code I added yesterday to
 which uses
profile page attributes to keep the data.

eemeli

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

Re: [pmwiki-users] A robust user registration module

[V.Krishn]

On Tuesday 25 May 2010 4:52:43 am Wordit Ltd wrote:
> On Mon, May 24, 2010 at 11:17 PM, V.Krishn  wrote:
> > I am guessing $secret is set by admin in some php file.
>
> config.php would be a good place.
>
> > Then secret would become permanent till those users exists,
> > and admin would not be able to change the secret when compromised.
>
> You can change a line in config.php whenever you like.
>
> > But then this would not be an issue as $password /s cannot easily be
> > known.
>
> If config.php is compromised then it's probably game over anyway.
> That's not really an issue in this context, just standard security for
> pmwiki and your web server.
>

Somehow I think sha1($email.$username.$password) should be sufficient.
Secondly,
As no user info(including email) is stored on server,
what would be the method to resend new password when lost?

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

-- 
Regards,
V.Krishn

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

On Mon, May 24, 2010 at 11:17 PM, V.Krishn  wrote:
>
> I am guessing $secret is set by admin in some php file.

config.php would be a good place.


> Then secret would become permanent till those users exists,
> and admin would not be able to change the secret when compromised.

You can change a line in config.php whenever you like.


> But then this would not be an issue as $password /s cannot easily be known.


If config.php is compromised then it's probably game over anyway.
That's not really an issue in this context, just standard security for
pmwiki and your web server.


Marcus

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

Re: [pmwiki-users] A robust user registration module

[V.Krishn]

On Tuesday 25 May 2010 12:00:46 am Wordit Ltd wrote:
> On Mon, May 24, 2010 at 2:24 PM, V.Krishn  wrote:
> > I am guessing you mean sha1($email.$username.$password)
>
> The secret string is the important thing to include. Build a hash
> containing whatever strings you want to verify, plus the secret, e.g.:
>
> sha1($email.$username.$password.$secret);

I am guessing $secret is set by admin in some php file.
Then secret would become permanent till those users exists,
and admin would not be able to change the secret when compromised.
But then this would not be an issue as $password /s cannot easily be known.

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

-- 
Regards,
V.Krishn

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

On Mon, May 24, 2010 at 2:24 PM, V.Krishn  wrote:
>
> I am guessing you mean sha1($email.$username.$password)

The secret string is the important thing to include. Build a hash
containing whatever strings you want to verify, plus the secret, e.g.:

sha1($email.$username.$password.$secret);


Marcus

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

Re: [pmwiki-users] A robust user registration module

[V.Krishn]

On Monday 24 May 2010 4:29:58 pm Wordit Ltd wrote:
> I just realised this a lot simpler than I thought. There is no need
> for temporarily storing the sign-up info.
>
> I think this should work:
>
> - user supplies email, username, password via a form
>
> - create a key containing supplied info plus a secret: sha1($email.).
>

Who provides the secret string?
if its just sha1($email) then its not difficult to create and get compromised.
I am guessing you mean sha1($email.$username.$password)

> - Mail to user. No record is kept because the key can be generated
> from info the returning user enters plus the secret.
>
> - user goes to verification page and enters the info plus the key. The
> key is checked.
>
> - if it matches, append, replace, or remove entry in wiki page
>
> The only general functions needed are to find a line in a wiki page,
> and write to a page. (I guess both these already exist as pmwiki
> functions?)
>
>
> Marcus
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users

-- 
Regards,
V.Krishn

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

I just realised this a lot simpler than I thought. There is no need
for temporarily storing the sign-up info.

I think this should work:

- user supplies email, username, password via a form

- create a key containing supplied info plus a secret: sha1($email.).

- Mail to user. No record is kept because the key can be generated
from info the returning user enters plus the secret.

- user goes to verification page and enters the info plus the key. The
key is checked.

- if it matches, append, replace, or remove entry in wiki page

The only general functions needed are to find a line in a wiki page,
and write to a page. (I guess both these already exist as pmwiki
functions?)


Marcus

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

Re: [pmwiki-users] A robust user registration module

[Peter Bowers]

On Fri, May 21, 2010 at 12:29 PM, Simon  wrote:
> I can't see a PITS entry for anything similar to this,
...
> Perhaps we should add a PITS entry and vote for it to gauge its popularity
> and define a short key feature set?

Yes, I agree. Voting will allow the community to express how important
they feel it is as well as soliciting input for a desired feature set.
I've taken the liberty to create this entry here:

http://pmwiki.org/wiki/PITS/01197

-Peter

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

Re: [pmwiki-users] A robust user registration module

[Wordit Ltd]

On Thu, May 20, 2010 at 5:08 PM, Hans  wrote:
>
> Is it a safe enough method to sent out a registration code to a new
> user, with a link and url parameters for automatic confirmation?


(Hans this is the thread I was referring to in my post on FoxNotify yesterday).

I had no problems using this method. If you want to be really secure
then just wrap a secret word into a hashed number instead of just a
random key, e.g. sha1($email.$secret).

I don't think hashing or encryption is necessary because all you need
is a unique number e.g. like short urls (youtube, bitly), and the
email address. A spammer or thief would need to guess both the number
and email. If you are still unsure just limit the allowed verification
attempts. It's simple and secure.

I have a sign-up script I wrote in PHP and used it for a site over
several months successfully. It had a few hundred subs, noticed no
problems. It was very simple. 95% of the code was form validation and
retrieving data.

What I did, and this might work for pmwiki, is to use a separate flat
file for the sign-ups. This keeps the real user list clean. On
successful verification, and that is simply comparing the email and
key, you copy the user data to where it's needed.

To unsub go the same way. Write the request to a temp file entry, when
successful, remove both the temp and real DB entries. I included the
current unix time so the sign-ups could also expire. Failed
subs/unsubs don't effect the real DB. All the junk stays in temp
files. You can also control sign-ups by IP logging. I used a PHP
script which writes to flat files, but one could just as well use
pmwikis built-in methods.


So my suggestion is to not mess with the actual wiki data until after
verification. This would also allow a general method of verification.
Cookbook authors can then select where and how they want to write the
verified data. It's really a feature pmwiki needs.

I hope that makes sense. I am willing to help, only my knowledge of
pmwiki coding is minimal. Since I've written such a script before and
used it in a working environment I can help in the design and whatever
code I can provide.


Marcus

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

Re: [pmwiki-users] A robust user registration module

[Eemeli Aro]

On 21 May 2010 13:29, Simon  wrote:
> Perhaps we should add a PITS entry and vote for it to gauge its popularity
> and define a short key feature set?

Honestly, I see the bigger problem with this as finding the person or
persons to write the code. Who's going to do it? I at least could
participate, but I think this needs to be a team effort for it to make
sense.

One challenge that I can think of straight away is that the current
AuthUser data format doesn't easily support the additional data fields
you'll need if you start adding new information, such as an e-mail
address for password resets or the confirmation code to match an
e-mail address verification link.

As a solution, I'd propose moving the data from SiteAdmin.AuthUser to
individual profile pages as page attributes which wouldn't be directly
accessible, much like the read/editt/attr passwords already are. But
again, this needs discussion -- which could well be done in PITS.

eemeli

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

Re: [pmwiki-users] A robust user registration module

[Simon]

I can't see a PITS entry for anything similar to this,
but I agree that this should be a core part of PmWiki, and PmWiki already
has "security" as part of its mojo.

This would provide a IMHO necessary adjunct to that, namely a means that
many people are familiar with,
of registering to edit, having to get the email and click on or enter an
approval code, to create a Userid (without which editing is disabled),
and a means to recover or reset password by email, or perhaps (later)
question and challenge.

Perhaps we should add a PITS entry and vote for it to gauge its popularity
and define a short key feature set?

Simon


On 21 May 2010 20:14, Hans  wrote:

> Thursday, May 20, 2010, 11:38:41 PM, Sameer Kumar wrote:
>
> > This reminds me of a longish conversation more than a year ago...
> > http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/53021/
>
> > I still believe that user authentication via email should be inbuilt into
> Pmwiki.
>
> thanks! Yes, it was discussed, and I am sorry I brought this up again!
> I agree with what you said then.
>
> Self-registration is the next best thing following a completely open
> wiki and an edit-locked wiki with an open readable password.
>
> Nothing has moved on this, which is a pity considering the power and
> flexibility of PmWiki. I am convinced the lack of a registration
> module is a serious turn-away for many site developers.
>
>  ~Hans
>
>
> ___
> pmwiki-users mailing list
> pmwiki-users@pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>



-- 

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

Re: [pmwiki-users] A robust user registration module

[Hans]

Thursday, May 20, 2010, 11:38:41 PM, Sameer Kumar wrote:

> This reminds me of a longish conversation more than a year ago... 
> http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/53021/

> I still believe that user authentication via email should be inbuilt into 
> Pmwiki.

thanks! Yes, it was discussed, and I am sorry I brought this up again!
I agree with what you said then.

Self-registration is the next best thing following a completely open
wiki and an edit-locked wiki with an open readable password.

Nothing has moved on this, which is a pity considering the power and
flexibility of PmWiki. I am convinced the lack of a registration
module is a serious turn-away for many site developers.

  ~Hans


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

Re: [pmwiki-users] A robust user registration module

[Sameer Kumar]

>
>
>  Yes, I agree with you as far as it should be a very simple thing
> to install. And it needs to be secure.
>
>
>  ~Hans
>


This reminds me of a longish conversation more than a year ago...
http://thread.gmane.org/gmane.comp.web.wiki.pmwiki.user/53021/

>
 I
still believe that user authentication via email should be inbuilt into
Pmwiki.
___
pmwiki-users mailing list
pmwiki-users@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

Re: [pmwiki-users] A robust user registration module

[Hans]

Thursday, May 20, 2010, 9:19:29 PM, Peter Bowers wrote:

>  My guess would be some other recipe wasn't playing nicely
> with wikish (or vice versa).

No. Only authuser.php is included, apart from what is asked for
on the AuthUserSignup page.
Result: when opening Login.Signup, I get a white page, and can't open
any other pages, as php or something is caught in a twist. I have to
restart all services (I use WAMP locally on XP).

> I tend to think it's not really ideal to have this functionality as a
> subset of a larger form processor, but to have something
> special-purpose instead.

Yes, I agree with you as far as it should be a very simple thing
to install. And it needs to be secure.


  ~Hans


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

Re: [pmwiki-users] A robust user registration module

[Peter Bowers]

On Thu, May 20, 2010 at 5:08 PM, Hans  wrote:
> PS: I just tried a new installation of it, as given on the recipe page.
> Created those Login pages, installed the scripts etc as described.
> then hitting white screens of death, or infinite page load times.
> I had to comment out all wikish lines in config and reboot the server.
> I am giving up on this for the moment, sorry, does not seem to be
> robust enough.

This is the single biggest disadvantage of authusersignup -- it's just
too much pain to install unless you're already using wikish otherwise
on your site.  It should be a single PHP script and a form on a page
or 2.

I'm pretty certain that the problems you ran into were not related to
the robustness or lack thereof of authusersignup but rather to the
unfortunate complexity of the installation or to cross-ups with other
recipes.  Documentation of the installation process is somewhat terse
in some points and a small change in the installation can lead to
unexpected/nonfunctional results.  Of course there's always the
possibility that a site's environment will be different, but this
recipe does not rely heavily on skin capabilities or something like
that...  My guess would be some other recipe wasn't playing nicely
with wikish (or vice versa).

> I could try and write an extension for Fox, to process the
> registration form and the confirmation form.
> But so far I never allowed Fox to write admin pages, to stay out of
> potential security problems.
> Although Fox can do mailing notifications already, I have not allowed
> Fox to mail to anywhere, the email targets need to be set on a
> template, or in config.

I tend to think it's not really ideal to have this functionality as a
subset of a larger form processor, but to have something
special-purpose instead.  But who am I to talk, having implemented
through wikish... :-)

-Peter

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

Re: [pmwiki-users] A robust user registration module

[Peter Bowers]

On Thu, May 20, 2010 at 3:52 PM, Oliver Betz  wrote:
> http://www.pmwiki.org/wiki/Cookbook/AuthUserSignup but this is IMO way
> too complicated. I would prefer a lightweight solution.

I agree.  In consideration of the security considerations (writing to
authorization-providing pages, etc.) it seems like something simple
and special-purpose would be the best idea.  I believe the *logic* of
AuthUserSignup could be re-written in PHP without an inordinate amount
of work, but obviously the person doing the work would need to decide
if that's the best way to do it.  The advantage is that it's a
somewhat proven concept since it's in use on several sites.

Unfortunately I can't volunteer right at this point due to other
commitments.  Any takers?

-Peter

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

Re: [pmwiki-users] A robust user registration module

[Eemeli Aro]

On 20 May 2010 15:16, Hans  wrote:
>
> I am looking for a robust user registration module,
> by which wiki users can register by choosing a user name and
> password, submit these together with name and email address,
> and get a confirmation email sent to them automatically, which
> they need to use in order to activate a new registered user account.
> It also needs to be easily administered using forms, and to cope
> with potential thousands of users.
>
> Any ideas if this can be put together as an add-on for PmWiki?
> Has it been done?

I've faced this same problem a couple of times, and ended up writing
MailmanAuth  as a
sufficient answer for my needs. There are similar solutions for other
systems as well, at least three or four for tying the authentication
to a Simple Machines Forum.

The thing is, user-friendly user registration & admin is not an easy
thing to get right, and since it hasn't been properly done (yet!) for
PmWiki, I've found it much easier to make someone or something else
handle it. Mailman does this pretty well and has a sufficient number
of users to trust that it's relatively robust, as well as providing a
web interface that proved surprisingly easy to scrape.

Also, if you're heading for thousands of users having a mailing list
isn't a bad idea, though at some point you might want to write your
own front-end to the registration given the slight weirdness in having
to register for a mailing list in order to edit a wiki.

OTOH, the next time I need something like this on a new site I'll
probably use OpenID. Haven't looked at how good the related PmWiki
recipes for that are, but it shouldn't be too difficult to get to
work.

eemeli

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

Re: [pmwiki-users] A robust user registration module

[Hans]

thanks Peter,

perhaps you are right, and AuthUserSignup is the only recipe allowing
confirmation via email. I may have to try it, but I am not too keen
to delve into wikish and having to learn shell scripting commands.

PS: I just tried a new installation of it, as given on the recipe page.
Created those Login pages, installed the scripts etc as described.
then hitting white screens of death, or infinite page load times.
I had to comment out all wikish lines in config and reboot the server.
I am giving up on this for the moment, sorry, does not seem to be
robust enough.

I could try and write an extension for Fox, to process the
registration form and the confirmation form.
But so far I never allowed Fox to write admin pages, to stay out of
potential security problems.
Although Fox can do mailing notifications already, I have not allowed
Fox to mail to anywhere, the email targets need to be set on a
template, or in config.

Is it a safe enough method to sent out a registration code to a new
user, with a link and url parameters for automatic confirmation?


  ~Hans


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

Re: [pmwiki-users] A robust user registration module

[Oliver Betz]

Hans wrote:

>I am looking for a robust user registration module,

Me too.

>by which wiki users can register by choosing a user name and
>password, submit these together with name and email address,
>and get a confirmation email sent to them automatically, which
>they need to use in order to activate a new registered user account.

Exactly.

An "I forgot my password, please send by mail" would also be very
useful.

And a "last logged in" field to detect zombie records.

>It also needs to be easily administered using forms, and to cope
>with potential thousands of users.

HtpasswdForm allows form based administration, but lacks the email
confirmation and the mandatory connection of an account to an email
address.

The mail address is also useful to contact people if needed.

> Has it been done?

http://www.pmwiki.org/wiki/Cookbook/AuthUserSignup but this is IMO way
too complicated. I would prefer a lightweight solution.

Oliver


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

Re: [pmwiki-users] A robust user registration module

[Peter Bowers]

On Thu, May 20, 2010 at 2:16 PM, Hans  wrote:
> I am looking for a robust user registration module,
...
>
> Any ideas if this can be put together as an add-on for PmWiki?
> Has it been done?

I think AuthUserSignup is the only existing thing that works with
AuthUser in its "normal" configuration (i.e., using a page to hold
usernames and passwords).  It is not sufficient for thousands of
users, I don't beleieve (although I don't have any solid reasons to
say that).  AuthUserSignup seems to be pretty solid and is in use on
several sites, but I would be hesitant to recommend it for a site that
was going to be seeing that much activity.  (Can authuser itself
handle thousands of users without performance concerns?)

HtpasswdForm is an alternative using .htpasswd files which, as I
understand, AuthUser handles.

AuthUserDbase goes a different direction, holding user/pass in a database.

UserAuth allows registration capability, but built on a totally
different security/authorization foundation.

To my knowledge that's an overview of the existing recipes -- are
there others out there?

-Peter

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

[pmwiki-users] A robust user registration module

[Hans]

I am looking for a robust user registration module,
by which wiki users can register by choosing a user name and
password, submit these together with name and email address,
and get a confirmation email sent to them automatically, which
they need to use in order to activate a new registered user account.
It also needs to be easily administered using forms, and to cope
with potential thousands of users.

Any ideas if this can be put together as an add-on for PmWiki?
Has it been done?


  ~Hans   


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