[pmwiki-users] Whither simple, dependable PmWiki login/self-registering mechanism?

Al Louis Ripskis ripskis at sprynet.com
Mon Mar 21 15:32:22 CDT 2011


>From some of the responses it appears there is a need for a simple, dependable PmWiki login/self-registering mechanism.
I took the liberty of pulling together below some of our recent activity on this subject. Unfortunately the first attempt didn’t work out.
The question is: Now what?
Does our user group have a procedure for handling such cases? Should we consult Pm on this?
Or does it pretty well depend on someone volunteering to take the lead and follow through?
I have an investigative reporting background and would be willing to do research, if some would point me in the right direction. For starters, which wiki engines on WikiMatrix are similar to our PmWiki? I just don’t know PHP.
I would hate to see this thread fade into the sunset, as Kirpi suggests, and indicates has happened in the past.
So how do you feel about this, and where do we go from here?
Thanks,
Al

Recent activity:
>From: Peter Bowers <pbowers at pobox.com>
>Sent: Mar 17, 2011 1:52 PM
>(1) I believe Al is talking about a signup mechanism rather than just
>a login.  In other words, some people coming in will have a login, but
>others will be coming brand new to the wiki and he wants them to have
>capability to sign up automatically with some kind of email
>confirmation and perhaps captcha or other spam-avoidance techniques.
>Al, correct me if I'm wrong here on what you're looking for.
>
>(2) I mentioned to Al the possibility of UserAdmin and that it was
>experimental at this point.  Just so nobody sees Eemeli's name as
>maintainer and wonders why it's not done...I made some suggestions and
>offered to help way back during the summer and then totally dropped
>the ball.  If I had kept my mouth shut (grin) you all would have a
>very nice user administration recipe now...  Sorry, Eemeli!
>
>-Peter


Peter, you are absolutely right, when you say:
>(1) I believe Al is talking about a signup mechanism rather than just
>a login.  In other words, some people coming in will have a login, but
>others will be coming brand new to the wiki and he wants them to have
>capability to sign up automatically with some kind of email
>confirmation and perhaps captcha or other spam-avoidance techniques.
>Al, correct me if I'm wrong here on what you're looking for.
I should have been more precise, but you got it right, that's exactly what I'm looking for.
Thanks again,
Al

On Mar 17, 2011, at 11:08 AM, Hans wrote:

Requirement: Have all pages locked against reading and editing,
except Main.HomePage, which should be open to be read, by protected
from editing.

My failed approach(es):
In config.php set a general 'admin' password,
plus a general 'edit' and 'read' password.
In page Main.Homepage?action=attr set the read password field to
@nopass

Why does this not work?

I would expect what you did to work. 

Did it fail in the simplest PmWiki configuration? Have you verified that Main.HomePage's read password was successfully changed to @nopass?

If you want to send me the config, a URL, and authorize me to look at the attributes, I'll see if I can figure out what's wrong.

Randy
________________
Thursday, March 17, 2011, 1:09:54 PM, Al Louis Ripskis wrote:

> Not being a programmer, and having extremely limited PHP skills, I
> need a simple login at the bottom of my newly constructed PmWiki home page saying:
> “If you would like read and upload access to the rest of the wiki, please login here.”

I thought this should be a simple matter knowing the flexibility of
PmWiki's password system, but I failed to find an answer.
Maybe someone more knowledgable can tell me why the following
approach fails, which I thought is the intuitively cottect one:

Requirement: Have all pages locked against reading and editing,
except Main.HomePage, which should be open to be read, by protected
from editing.

My failed approach(es):
In config.php set a general 'admin' password,
plus a general 'edit' and 'read' password.
In page Main.Homepage?action=attr set the read password field to
@nopass

Why does this not work?

I tried  a more complicated variation, by setting in page
Main.GroupAttributes?action=attr  a password for read and edit,
and setting it the same as in config.php, all in addition
to what I done before.

This did not work either.

As soon as I log out on Main.HomePage, I am prompted for a password
to enter. So read=@nopass had no effect.

As to the login requirement; a login link on Main.homePage like this
should do:
[[{$FullName}?action=login| If you would like read and upload access
to the rest of the wiki, please login here]]
and perhaps putting it in a box and adding some color/bigger text to
make it more visible. But of course that does not help if the home
page stays read protected despite setting read=@nopass.

Can someone help with this please?
  ~Hans


Thursday, March 17, 2011, 6:10:49 PM, Randy Brown wrote:

> I would expect what you did to work. 

> Did it fail in the simplest PmWiki configuration? Have you verified
> that Main.HomePage's read password was successfully changed to @nopass?

yes. No included recipe scripts.

Excerpt from the page file:

version=pmwiki-2.2.24 ordered=1 urlencoded=1
agent=Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
author=
charset=ISO-8859-1
csum=
host=127.0.0.1
name=Main.HomePage
passwdread=@nopath

Excerp from config.php

$DefaultPasswords['admin'] = crypt('admin');
$DefaultPasswords['auth'] = crypt('auth');
$DefaultPasswords['edit'] = crypt('edit');
$DefaultPasswords['read'] = crypt('read');

Main.HomePage requires password

As you see this is running on my local machine, just for testing.

I checked this on another test site on my computer, with same result.
  ~Hans






More information about the pmwiki-users mailing list