[pmwiki-users] RecipeCheck question

2010-05-21 Thread Ingersoll, Nelson
Hi, 

   I cannot use the online recipe checker because my Wiki is behind a company 
firewall.  So I downloaded and installed CookBook::RecipeCheck.  After running 
it I updated various recipes which were way out of date.  However, two recipes 
show no datestamp on PmWiki.org.  They are Cookbook:ZAP and 
Cookbook:CommentBoxPlus.

   I picked up these recipes on PmWiki.org and am wondering what the lack of a 
pmwiki.prg datestamp means.  Are the recipes deprecated or unsupported?  I am 
running PmWiki 2.2.16 at this time.

   Thank you for your help.

Regards, 
Nelson

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


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

2010-05-21 Thread 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

2010-05-21 Thread 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

2010-05-21 Thread 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] Odd change in behaviour on logged in session retention

2010-05-21 Thread Andy Gaskell
Thanks Petko and Dave for you replies.  Both were greatly appreciated.

I changed the session path, though this didn't solve the problem, it
did allow me to see the session cookies being created, which was good.

Then, as per Petko's suggestion, I updated (to 2.2.16) and this solved
the problem.  You've been a great help again Petko, merci beaucoup.

Andy


On 21 May 2010 01:14, Petko Yotov <5...@5ko.fr> wrote:
> On Friday 21 May 2010 01:05:15, Andy Gaskell wrote :
>> 1: Visit a page on a authenticate-to-read group, it asks for a
>> username and password.
>> 2: Click edit and it asks for a username and password again.
>> 3: Click save and it asks for a username and password again, twice.
>>
> ...
>> PmWiki: 2.2.0-beta67
>> php: 5.3.2
>
> Hello. PHP 5.3 changed a number of things and we've been tracking and fixing
> them in recent versions. You can upgrade to the latest version of PmWiki --
> the problem you describe should be fixed now.
>
> Please make backups and read the release notes between beta67 and 2.2.16
> because some changes may affect your wikis.
>
>  http://www.pmwiki.org/wiki/PmWiki/ReleaseNotes
>  http://www.pmwiki.org/wiki/PmWiki/Upgrades
>
> Thanks,
> Petko
>
>



-- 
Andy Gaskell
Head Designer and Developer
Software Systems: Open For Business
Email: a...@ssofb.co.uk
Mobile: 07745 924 449
Office: 01224 637584
Skype: andy_at_ssofb
Office: 58 Mid Stocket Road, Aberdeen, AB15 5JB.
Limited company: SC347800

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


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

2010-05-21 Thread 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