phpwiki-talk

[Phpwiki-talk] Offering some graphics

[<xi...@yi...>]

Hello:

My strength is really in graphics rather than coding, so I have been 
working on customizing the included themes for phpwiki 1.3.3 and I 
wondered if perhaps some of my work would be helpful to others.

I have taken the "MacOSX" buttons through Photoshop and turned them all 
into buttons (still pngs, although I think a gif version would even 
look right in NS4) with TRUE transparent borders, so that they can be 
used with other backgrounds. They now look great on any colored (or 
patterned) background in IE 5+ or NS6. I have also created a lightly 
colorized version, for variety.

Anyway, I would am already developing themes for my personal use with 
phpwiki, and would be happy to place some of them at the disposal of 
others in the group who would like to try them. So if there is any 
interest, kindly guide me as to where these could be uploaded, or where 
links could be posted, etc. to make them available to the group.

Thanks and best wishes to all.

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

Re: [Phpwiki-talk] Email Notification question

[Reini U. <ru...@x-...>]

Robert Orenstein schrieb:
> Here's a short version of my longer question: is EmailNotification
> going to be implemented anytime soon? If not, I'll probably wind up
> trying to write the code myself for our site, but if someone else
> is working on it, and if it'll be available shortly, I'll probably
> hold off.
...
> Anyway. Is this in the works, or should I assume that I should start
> hacking?

It's in the works, but before the userauth and preferences have to be 
finished, because I want EmailNotification to be based on that.
1-2 weeks probably. pear/Cache issues and wrong permissions needed more 
time than I thought.

I want a non-public list, either as private list in the UserPreferences 
(preferred) or in each page accessible only by the authuser.
For a public solution (as in other wiki's) or admin-only there were some 
patches.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] ImageLinks revisited

[Willie D. L. <wd...@ic...>]

On Sat, 17 Aug 2002, Reini Urban wrote:

> BTW: I changed my local VisualWiki somewhat. The default cache_dir param 
> on windows was broken. I'll send you a patch sooner or later.
> I also improved the help page and simplified the valid image extensions.
> 
> Something like this for the start:
> 
> --- ./lib/plugincache-config.php~	2002-03-10 09:54:16.000000000 +0000

I didn't find this file on my PhpWiki installation. Is the filename correct?

Thanks in advance,
Willie D. Leiva

[Phpwiki-talk] Email Notification question

[Robert O. <rl...@pe...>]

Hi,

Here's a short version of my longer question: is EmailNotification
going to be implemented anytime soon? If not, I'll probably wind up
trying to write the code myself for our site, but if someone else
is working on it, and if it'll be available shortly, I'll probably
hold off.

Here's a longer version:

I recently installed PHPWiki at our company. I let a few people
at the company know about it, and we used it a lot for a couple of
projects for the first few days. After that, it sort of petered
out... mostly, we forget to check it.

What happened was that there were four of us on the Wiki, and
a few days went by where only I made Wiki postings. I kept on
checking the RecentChanges page, but no-one had posted anything
right away, and by the time they did, I had stopped going back
regularly to check to see if they'd posted. And by the time I went
back, they stopped going back, etc.

The problem, it seems to me, is that the Wiki is purely a pull technology.
And it's true that email is also a pull technology, but over the last
ten years it's essentially become a push technology, because
everyone checks their email, all the time. (You could call email
a virtual push technology).

If EmailNotification was implemented for the Wiki, I suspect (but
obviously don't know for sure) that our Wiki usage would shoot up.
We wouldn't have to remember to view the Wiki because we'd be
attaching the Wiki to our (effective) push messaging.

A side note here: I do find it interesting that the Wiki isn't enough
even for the hardcore Wiki lovers on this mailing list -- if it was
enough, presumably the mailing list wouldn't be necessary, because
you'd all be checking the Wiki regularly. When I started writing this
message, I had a choice of posting it on the Wiki or sending out email --
I chose email because it was the only way I had of guaranteeing that
the people I wanted to see the message, WOULD see the message! I'd like
to ask those of you who send email to this list: why do you send the
email instead of posting to the Wiki? Is it for the reasons I've given
above, or is there something else going on? It does seem to me that
if EmailNotification were available, this mailing list could cease
to exist.

Anyway. Is this in the works, or should I assume that I should start
hacking?

Thanks,

Robert Orenstein
Perforce Software

[Phpwiki-talk] SubPages and ImageLinks on PhpWikiDemo

[Reini U. <ru...@x-...>]

I updated the sf.net demo site with my latest CVS checkins:
http://phpwiki.sourceforge.net/demo/en/ReiniUrban
The nightly snapshot includes this also.
   http://phpwiki.sf.net/nightly/phpwiki.nightly.tar.gz

Note, that if the logged-in user has a calendar subpage, he get's a 
"Today" button, to enable weblogging.

   <UserHomePage>: [ /Calendar ]
   <UserHomePage>/Calendar: <?plugin Calendar ?>

In english <UserHomePage>/Calendar, in german <UserHomePage>/Kalender 
and so on. see your locale/po/<lang>.po

The sf.net:/usr/share/pear DB module is hopelessly old, so I had to 
patch the demo version of lib/WikiDB/backend/PearDB.php to use our own 
private pear copy for DB, but I still use the pear version of the Cache 
module. I don't want to add this to our CVS also. But sooner or later we 
should get rid of our CVS copy of pear DB. Probably later than sooner :)

I submitted a sf.net bugreport to upgrade pear (one year old) - at least 
DB - and php, which is still 4.1.2. One could get root access by some 
known php exploits and upgrade /usr/share/pear/DB :)

Now I work on UserAuth and the permissions as discussed.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: proposed security additions

[<xi...@yi...>]

>If I can find time, I'll try to check something like this into CVS next
>week.  I think it would probably be useful to have a simple two-user
>option like this even after Reini's full multi-user support is available.

>It would be much simpler (codewise) (and the point of this hack is
>simplicity, after all) if these were just stored as a PHP hash in
>index.php, like:
>
>   $WikiUsers =3D array( 'JeffDairiki' =3D> 'JeffsPassword',
>                       'JohnKershaw' =3D> 'Your Password' );

>  > Or maybe a third option, a half-way house: one password that fits any
>>  WikiWord login name?
>
>Interesting idea.  I think it's probably appropriate for certain
>situations.

I am hoping that, while we await Reini's ultimate solution, these options=
 will be made available, even if as a separate file or a set of=
 instructions to be implemented "by hand" (much like John's directions for=
 my request). Thanks to any of you who come forth with all or part of this.

Re: [Phpwiki-talk] To clarify re:security question

[Reini U. <ru...@x-...>]

Jeff Dairiki schrieb:
>>If you're going to go to the trouble, could you make it that 
>>the username/password pairs are stored in a text file that would be 
>>easily edited.
> 
> It would be much simpler (codewise) (and the point of this hack is
> simplicity, after all) if these were just stored as a PHP hash in
> index.php, like:
> 
>   $WikiUsers = array( 'JeffDairiki' => 'JeffsPassword',
>                       'JohnKershaw' => 'Your Password' );
> 
> Would that be okay?

Nope, too simple.
But I'll add AUTH_FILE also (pointing to /etc/passwd or any .htpasswd 
file), besides AUTH_DNS, AUTH_IMAP and AUTH_LDAP, which already works 
for me.
The .htpasswd solution is then an __optional__ Apache HTTP_AUTH 
solution, in contrast to a __required__ Apache HTTP_AUTH. With 
REQUIRE_HTTP_AUTH you __must__ login before you get to any page, with 
REQUIRE_AUTH_USER you try any of the supported auth mechanisms:
(PASS, FILE, DNS, IMAP, LDAP, BOGO, NONE).

I'll probably commit tomorrow, without groups and userprefs, when I get 
the permission checks correct. Jeff's page-meta data abstraction lib 
(WikiDB_Page::get) is perfect for this, probably better than a seperate 
table.
So I'll do the groups, permissions and user preferences (email, ...) in 
a wikipage, only the passwords are from the AUTH mechanism.
I don't really want to store the password in the page, besides I do want 
to have passwords for my group only at one single place. (radius or imap 
preferred). So it get's easily changed and remembered.

>>Or maybe a third option, a half-way house: one password that fits any 
>>WikiWord login name?
> Interesting idea.  I think it's probably appropriate for certain
> situations.

well, that's a good option for simple groups.
Maybe REQUIRE_AUTH_PASS?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] To clarify re:security question

[John K. <jo...@ke...>]

>  > If you're going to go to the trouble, could you make it that
>>  the username/password pairs are stored in a text file that would be
>>  easily edited.
>
>It would be much simpler (codewise) (and the point of this hack is
>simplicity, after all) if these were just stored as a PHP hash in
>index.php, like:
>
>   $WikiUsers = array( 'JeffDairiki' => 'JeffsPassword',
>                       'JohnKershaw' => 'Your Password' );
>
>Would that be okay?

That would be fine. Stored in index.php?

>  > Or maybe a third option, a half-way house: one password that fits any
>>  WikiWord login name?
>
>Interesting idea.  I think it's probably appropriate for certain
>situations.

How about:

  $WikiUsers = array( 'JeffDairiki' => 'JeffsPassword',
                       'JohnKershaw' => 'Your Password',
                       '*' => 'General Password' );

John.
-- 
------------------------------------
     0113 2289316 / 07944 755613
jo...@ke... / www.kershaw.org
  AOL johnkershaw / Y! john_m_kershaw
------------------------------------

Re: [Phpwiki-talk] To clarify re:security question

[Jeff D. <da...@da...>]

> If you're going to go to the trouble, could you make it that 
> the username/password pairs are stored in a text file that would be 
> easily edited.

It would be much simpler (codewise) (and the point of this hack is
simplicity, after all) if these were just stored as a PHP hash in
index.php, like:

  $WikiUsers = array( 'JeffDairiki' => 'JeffsPassword',
                      'JohnKershaw' => 'Your Password' );

Would that be okay?

> Or maybe a third option, a half-way house: one password that fits any 
> WikiWord login name?

Interesting idea.  I think it's probably appropriate for certain
situations.

Re: [Phpwiki-talk] To clarify re:security question

[John K. <jo...@ke...>]

>  > Wise ones please check this and make sure I haven't got it wrong.
>>  Seems to work for me.
>
>It looks right to me.  Thank you, John, very much for fleshing it
>out (and testing).
>
>If I can find time, I'll try to check something like this into CVS next
>week.  I think it would probably be useful to have a simple two-user
>option like this even after Reini's full multi-user support is available.

I've tried to follow the stuff about Unix-style permissions and 
failed! A simple option like this for 'the rest of us' would be 
great. If you're going to go to the trouble, could you make it that 
the username/password pairs are stored in a text file that would be 
easily edited.

Or maybe a third option, a half-way house: one password that fits any 
WikiWord login name? That way I can tell everyone a single password, 
but their login name is still attached to their alts.

Is this a good or bad idea?

John.
-- 
------------------------------------
     0113 2289316 / 07944 755613
jo...@ke... / www.kershaw.org
  AOL johnkershaw / Y! john_m_kershaw
------------------------------------

Re: [Phpwiki-talk] To clarify re:security question

[Jeff D. <da...@da...>]

> Wise ones please check this and make sure I haven't got it wrong. 
> Seems to work for me.

It looks right to me.  Thank you, John, very much for fleshing it
out (and testing).

If I can find time, I'll try to check something like this into CVS next
week.  I think it would probably be useful to have a simple two-user
option like this even after Reini's full multi-user support is available.

Re: [Phpwiki-talk] To clarify re:security question

[Jeff D. <da...@da...>]

I think it's great your working on this Reini!

Here's a few comments:

On Sat, 17 Aug 2002 12:29:04 +0100
Reini Urban <ru...@x-...> wrote:

> Just a note that I'm just testing some userauth code I've written.
> 
> * unix like filesystem permissions per page,

 There was some discussion about this awhile ago.  Basically the
 two reasonable choices seemed to be a unix permission model
 (which is simple and understandable for us unix geeks),
 or a more windows-like access control list
 (more familiar to windows guys (maybe), offers more control,
 probably a bit harder to code...)

> * a user and group table,

 This seems hard to get around, no matter what, but certainly
 adds complexity and ugliness...  I think there were ideas
 before about keeping the group membership data in wiki pages
 (as wiki text).  Something like, if PhpWiki wants to check to
 see if JohnDoe is a member of LunchGroup:
   1. Look at wiki page UserGroupLunchGroup (or something).
   2. Make sure that that has reasonable permissions and ownership.
      (In the current perm model: it must be locked.)
   3. Look for the line:
          * JohnDoe
      (or similar) within the text of the page.

 This avoids new tables, makes it easy for the admin to edit
 the group tables, and makes (possibly) public accessible group
 membership lists.

> the mysql schema:
> CREATE TABLE user (
>    userid int(10) unsigned NOT NULL auto_increment,
>    username char(16) binary NOT NULL default '',
>    password char(16) binary NOT NULL default '',
>    PRIMARY KEY  (userid)
> ) TYPE=MyISAM;

username should be (enforced) unique.

char(16) may not be enough.  I think it would be nice to use
wiki-words, like JeffDairiki as userids, and reasonable ones
could easily be longer than 16 characters.


> INSERT INTO user VALUES (1, 'ReiniUrban', 'somecryptedpassword');
> CREATE TABLE member (
>     memberid int(10) unsigned NOT NULL auto_increment,
>     userid int(10) unsigned NOT NULL default '0',
>     name char(16) NOT NULL default '',
>     PRIMARY KEY  (memberid),
>     KEY userid (userid)
>   ) TYPE=MyISAM;

I'd suggest, instead, two tables (based on /etc/group)

CREATE TABLE group (
      name char(16) NOT NULL,
      groupid int NOT NULL auto_increment,
      PRIMARY KEY (groupid)
)

CREAT TABLE members (
      userid int NOT NULL,
      groupid int NOT NULL,
      KEY userid (userid),
      KEY groupid (groupid)
)

Or better yet, the group-tables-in-wiki-pages idea outlined above.
        

> INSERT INTO member VALUES (1, 1, 'admin');
> CREATE TABLE permissions (
>    pageid int(11) unsigned NOT NULL default '0',
>    userid int(11) unsigned NOT NULL default '0',
>    memberid int(11) unsigned default NULL,
>    permission int(11) unsigned NOT NULL default '776',
>    PRIMARY KEY  (pageid),
>    KEY userid (userid),
>    KEY memberid (memberid)
> ) TYPE=MyISAM;

Permissions/ownership information can easily be stored
in page meta data.  The current WikiDB backend supports
attaching arbitrary key/value pairs to each page
(and also each page revision).
The interface is through the WikiDB_Page::get()
and WikiDB_Page::set() methods (see lib/WikiDB.php).

The only issues with doing this are:

  If any sensitive data are stored that way (e.g. passwords),
  the _DebugInfo plugin (among possibile other things) will
  have to be fixed so that that information won't be
  exposed to prying eyes...

  Pick keynames which won't clash with other key names.
  We need to come up with better docs about what keys
  are used, and a system for picking new names, but
  I think most/all of the currently used keys are 
  listed in the docs in WikiDB.php.

  One can't search the db (efficiently) for meta data.
  I don't think this is a big issue in this case.
  It will make operations like "show me all pages
  owned by JeffDairiki" slow (linear search), but
  I don't think that's a big deal...


Other issues to think about:

Self Registration

  It has been a long stated goal of PhpWiki to implement an
  automatic self-registration system where new users can 
  register themselves, along with their e-mail addresses;
  Then their initial password is mailed to their e-mail
  address (or some other similar scheme) --- they idea
  being that by making sure everyone at least has a valid
  e-mail address, you avoid completely bogus/untraceable
  users.

  When/if this gets implemented, we'll need to be able to
  store other "user meta-data" in the user table.  (E.g.
  e-mail address.)

User Table in Wiki Page(s)

  You suggested this too.

  I have yet to see a clean way to do this, but it would sure
  be nice to have this as an option.  The big attraction
  of this is:
    * It's easily/guaranteeably portable to any server/platform
      which supports PhpWiki.
    * The mechanism for editing the user data is already built
      into PhpWiki.
    * (If done right) public user information is automatically 
      publically viewable (& searchable, etc...)

  An idea on this lines (which I think I still favor) is to 
  have one page per user.  The page name is the username.
  Password and other sensitive information is stored in the
  page meta-data.  (Anything stored in meta-data will take
  special code to edit.)  All non-sensitive information
  is stored in the wiki-text.  This has been discussed before,
  and I remember that not everyone was as excited about the idea
  as I was...

Re: [Phpwiki-talk] Re: Reini Urban's ideas

[Reini U. <ru...@x-...>]

xi...@yi... schrieb:
> Your ideas look very worthwhile and interesting to me. Forgive my 
> ignorance of specific php issues, but a general concern has occurred to 
> me which might (or might not) be pertinent:
> 
> "Each page permission defaults to 766."
> 
> Many webservers (like my host's) are now running SuEXEC, which (I am 
> told) gives an error if any permissions are set higher than 755. Would 
> that apply to what you are discussing (or should I just be quiet now)?
> 
> Anyway, it is exciting to see the development that is going on here.

No.
I was referring to pure virtual file permissions on phpwiki pages which 
normally come from a database backend. this has nothting to do with the 
phpwiki setup on any server.

each page has three groups:
owner, group and the rest. (no setuid so far. ignore the first digit 
from the manpage)
each number in 0766 refers those groups.
the bits in the number refer to permissions:

$ man chmod
     A numeric mode is from one to  four  octal  digits  (0-7),
     derived  by  adding  up  the bits with values 4, 2, and 1.
     Any omitted digits are assumed to be leading  zeros.   The
     first  digit  selects the set user ID (4) and set group ID
     (2) and save text image (1) attributes.  The second  digit
     selects  permissions  for the user who owns the file: read
     (4), write (2), and execute (1); the third selects permis-
     sions  for  other users in the file's group, with the same
     values; and the fourth for other users not in  the  file's
     group, with the same values.

so 766 are the current default permissions with ALLOW_BOGO_LOGIN
is true for any non-locked page. a locked page has 744.

by using a owner we overcome the only-one admin problem. any user can 
add a private page (0700) to any wiki. only admins can read/write these.

by using groups you can restrict a set of pages to your internal 
development group, which cannot be done by simple HTTP_AUTH or any
other auth plugin (phplib, phpnuke, ...)
eg. a 770 page with owner "ReiniUrban.dev" can only be read/changed by 
me or any member of the "dev" group.
or 774 for non-public write-access.

I just have to think about the execute flag. See 
http://phpwiki.sourceforge.net/phpwiki/WikiPageMailBoxFormat for better 
ideas for such "executables". There I seperated the page permissions 
into header and page.
   X-Phpwiki-HeaderPermissions: -rwxr-xr-x
   X-Phpwiki-BodyPermissions:   -rwxrwxrwx
So we can limit the users who can change the permissions.
Now (well soon) everybody with write access can change the body and header.


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] ImageLinks revisited

[Reini U. <ru...@x-...>]

Johannes Grosse schrieb:
> On Fri, 16 Aug 2002, Reini Urban wrote:
>>I ported my old implementation of Imagelinks now the latest phpwiki
>>version. Keeping the metaphor [ linkname | url ] the linkname is what
>>gets displayed. here the inlined image. the url is the target, here the
>>pagenamed linked to.
>>
>>   [ img | link ]
>>like [images/prev.gif|PrevLink][images/next.gif|NextLink]
>>as described in http://phpwiki.sourceforge.net/phpwiki/ImageLinks
> 
> What about real urls in the 'link' part of [img|link]?
> Is it already possible or do you only allow WikiPage links?
> This feature would allow us to add thumbnails of the form
>   [ http://www.myhome.com/thumb.jpg | http://www.myhome.com/picture.jpg ]

Yes, internal pages (resp. $Theme subdir data) and external urls are 
supported.
In my last 1.2.x implementation I had border=1 on external links because 
it might be a security risk on including external cgi's ending with gif, 
but with 1.3.3 not anymore.
hmm... when you see the border it was already to late...

> Perhaps, this is premature, since we have no real uploading scheme,
> so you always have to link to a homepage, but I think there are
> situation (look at the VisualWiki page), where this might be useful.
> 
> BTW Is there any work on an upload/attachment mechanism?
>     I think the subpage syntax would be nice
>       (WikiPage/AttachMent1.jpg)

not yet.
BTW: I changed my local VisualWiki somewhat. The default cache_dir param 
on windows was broken. I'll send you a patch sooner or later.
I also improved the help page and simplified the valid image extensions.

Something like this for the start:

--- ./lib/plugincache-config.php~	2002-03-10 09:54:16.000000000 +0000
+++ ./lib/plugincache-config.php	2002-08-03 14:40:09.000000000 +0000
@@ -80,7 +80,9 @@
  $CacheParams = array(
      // db settings (database='file' is the fastest)
          'database'        => 'file',
-        'cache_dir'       => '/tmp/cache/',
+        'cache_dir'       => (substr(PHP_OS,0,3) == 'WIN')
+ 
                        ? ($GLOBALS['HTTP_ENV_VARS']['TEMP'] . "\\cache\\")
+ 
                        : '/tmp/cache/',
          'filename_prefix' => 'phpwiki',


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Reini Urban's ideas

[<xi...@yi...>]

Your ideas look very worthwhile and interesting to me. Forgive my 
ignorance of specific php issues, but a general concern has occurred to 
me which might (or might not) be pertinent:

"Each page permission defaults to 766."

Many webservers (like my host's) are now running SuEXEC, which (I am 
told) gives an error if any permissions are set higher than 755. Would 
that apply to what you are discussing (or should I just be quiet now)?

Anyway, it is exciting to see the development that is going on here.

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

[Phpwiki-talk] Success! and a sheepish grin...

[<xi...@yi...>]

Well... post in haste, be embarrassed in leisure... Upon checking again 
VERY carefully, I found that one of the '}' characters got lost in the 
cut-and-paste operations. Once it was restored (and the database tables 
cleared yet again), IT WORKED!!!

With preliminary testing, it appears that the "user" functions exactly 
as I wanted it to do, with no more and no less capability than I wanted 
it to have. Perfect!

So I am really pleased and excited at what I can now do with this extra 
security functionality for all of my wikis.

Brilliant, you guys! And thank you for the prompt and patient help.
      
       

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

Re: [Phpwiki-talk] ImageLinks revisited

[Johannes G. <jg...@qf...>]

On Fri, 16 Aug 2002, Reini Urban wrote:

> I ported my old implementation of Imagelinks now the latest phpwiki
> version. Keeping the metaphor [ linkname | url ] the linkname is what
> gets displayed. here the inlined image. the url is the target, here the
> pagenamed linked to.
>
>    [ img | link ]
> like [images/prev.gif|PrevLink][images/next.gif|NextLink]
> as described in http://phpwiki.sourceforge.net/phpwiki/ImageLinks
>

What about real urls in the 'link' part of [img|link]?
Is it already possible or do you only allow WikiPage links?

This feature would allow us to add thumbnails of the form

  [ http://www.myhome.com/thumb.jpg | http://www.myhome.com/picture.jpg ]

Perhaps, this is premature, since we have no real uploading scheme,
so you always have to link to a homepage, but I think there are
situation (look at the VisualWiki page), where this might be useful.

BTW Is there any work on an upload/attachment mechanism?
    I think the subpage syntax would be nice
      (WikiPage/AttachMent1.jpg)

regs
Jo

Re: [Phpwiki-talk] To clarify re:security question

[Reini U. <ru...@x-...>]

Just a note that I'm just testing some userauth code I've written.

* unix like filesystem permissions per page,
* a user and group table,
* authentification via HTTP_AUTH (let apache mod_auth_* handle it),
   a new user table (maybe from a seperate db, like a radius),
   or via external auth (currently LDAP and IMAP).

Each page permission defaults to 766.
The executable bit (7) should allow/disallow some active plugins,
like EmailNotification.
There's a owner (creator), groupmember and world.
There's no directory like permission hierarchy (yet).

the mysql schema:
CREATE TABLE user (
   userid int(10) unsigned NOT NULL auto_increment,
   username char(16) binary NOT NULL default '',
   password char(16) binary NOT NULL default '',
   PRIMARY KEY  (userid)
) TYPE=MyISAM;
INSERT INTO user VALUES (1, 'ReiniUrban', 'somecryptedpassword');
CREATE TABLE member (
    memberid int(10) unsigned NOT NULL auto_increment,
    userid int(10) unsigned NOT NULL default '0',
    name char(16) NOT NULL default '',
    PRIMARY KEY  (memberid),
    KEY userid (userid)
  ) TYPE=MyISAM;
INSERT INTO member VALUES (1, 1, 'admin');
CREATE TABLE permissions (
   pageid int(11) unsigned NOT NULL default '0',
   userid int(11) unsigned NOT NULL default '0',
   memberid int(11) unsigned default NULL,
   permission int(11) unsigned NOT NULL default '776',
   PRIMARY KEY  (pageid),
   KEY userid (userid),
   KEY memberid (memberid)
) TYPE=MyISAM;


But maybe we should define a flag for each allowed action?
(remove, rename, edit, zipdump, ...)
I'm for simplicity here.

When it's ready I'll commit it then, together with the "/" SubPages and 
ImageLinks.

PS: Some year ago I wanted to put this page meta information 
(permissions, ...) into some kind of page header (mbox format), and the 
user and group table into simple only admin-readable pages. For now just 
this. The DB backends are probably heavy to write, compared to the page 
extraction changes for the mbox format, but it should be quite simple 
for the complicated DB backends (DBA).
The users and member doesn't really need names and id's. hmm.

Jeff Dairiki schrieb:
> I suspect what you want can be done with (as you suggest)
> just a few lines of changes.  
> 
> Here's a basic outline of what you need to do (I think):
> 
>    1. In lib/WikiUser.php, you need to modify the WikiUser::_pwcheck()
>       so that it returns WIKIAUTH_USER when a given a valid
>       regular username, password pair.
> 
>    2. In main.php, you need to modify WikiRequest::requiredAuthority()
>       so that it returns WIKIAUTH_USER for action 'edit' (currently
>       it returns either WIKIAUTH_ANON or WIKIAUTH_BOGO depending
>       on the setting of REQUIRE_SIGNIN_BEFORE_EDIT.)
> 
> Both are simple changes.
> 
> I think that should do it, but I haven't tested it.
> If that's not enough help, let me know and I'll try to put
> together a set of patches.  I won't have time to do that
> until sometime next week though...
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Jeff's & John's suggestions

[<xi...@yi...>]

First of all, thanks to both Jeff (who is giving me too much credit for 
coding knowledge, but the IDEA made sense to me anyway) and John. The 
step-by-step guide (John) is exactly the level of detail I needed. 
Unfortunately... here is the error message I got when I attempted to 
load my wiki (and I got the same error again even after emptying the 
tables of the database and trying again):

Parse error: parse error, unexpected ';', expecting T_OLD_FUNCTION or 
T_FUNCTION or T_VAR or '}' 
in /home/mysite/public_html/wiki/01/lib/WikiUser.php on line 158

Fatal error: Cannot instantiate non-existent class: wikiuser 
in /home/mysite/public_html/wiki/01/lib/main.php on line 139

------

So what do you think is the problem? I will look at this in a line-
numbering editor to see what exactly is on the "offending" lines, but 
if you can help me with this I will be most appreciative.

By the way, I am assuming that I would leave the settings for anonymous 
login and BOGO login turned off (false) as I already had them in 
index.php.

Could there be a problem with the fact that index.php still contains 
references to anon and BOGO logins (even though they are set 
to "false"), while the references to them in main.php got deleted with 
that third edit in John's instructions?

I feel we are almost there, and look forward to the solution. Thanks!  
   
       

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

Re: [Phpwiki-talk] To clarify re:security question

[John K. <jo...@ke...>]

>  > ... perhaps I should have put glowing neon lights
>  > and dancing animated gifs around the word "simple" in my request.

Hi,

In case Jeff's explantion needs additional simplification, here's the 
step-by-step version :)
Wise ones please check this and make sure I haven't got it wrong. 
Seems to work for me.


All file paths are relative to the phpwiki folder.

* Open index.php
* Find: define('ADMIN_USER', "admin");
* Add two new lines under the ADMIN_PASSWD line:

  define('RESTRICTED_USER', "user");
  define('RESTRICTED_PASSWD', "test");

* Now open lib/WikiUser.php
* Scroll to the end and replace the whole of the _pwcheck function with this:

     function _pwcheck ($userid, $passwd) {
         global $WikiNameRegexp;
        
         if (!empty($userid) && $userid == ADMIN_USER) {
             if (!empty($passwd) && $passwd == ADMIN_PASSWD)
                 return WIKIAUTH_ADMIN;
             return false;
         }
         elseif (!empty($userid) && $userid == RESTRICTED_USER) {
             if (!empty($passwd) && $passwd == RESTRICTED_PASSWD)
                 return WIKIAUTH_USER;
         }
         return false;
     }

* Finally open lib/main.php
* Halfway down you'll find this:

             case 'edit':
                 if (defined('REQUIRE_SIGNIN_BEFORE_EDIT') && 
REQUIRE_SIGNIN_BEFORE_EDIT)
                     return WIKIAUTH_BOGO;
                 return WIKIAUTH_ANON;

Replace it with this:

             case 'edit':
                 return WIKIAUTH_USER;


I think that should do it.

John.
-- 
------------------------------------
     0113 2289316 / 07944 755613
jo...@ke... / www.kershaw.org
  AOL johnkershaw / Y! john_m_kershaw
------------------------------------

Re: [Phpwiki-talk] To clarify re:security question

[Jeff D. <da...@da...>]

> ... perhaps I should have put glowing neon lights 
> and dancing animated gifs around the word "simple" in my request. 

I suspect what you want can be done with (as you suggest)
just a few lines of changes.  

Here's a basic outline of what you need to do (I think):

   1. In lib/WikiUser.php, you need to modify the WikiUser::_pwcheck()
      so that it returns WIKIAUTH_USER when a given a valid
      regular username, password pair.

   2. In main.php, you need to modify WikiRequest::requiredAuthority()
      so that it returns WIKIAUTH_USER for action 'edit' (currently
      it returns either WIKIAUTH_ANON or WIKIAUTH_BOGO depending
      on the setting of REQUIRE_SIGNIN_BEFORE_EDIT.)

Both are simple changes.

I think that should do it, but I haven't tested it.
If that's not enough help, let me know and I'll try to put
together a set of patches.  I won't have time to do that
until sometime next week though...

[Phpwiki-talk] To clarify re:security question

[<xi...@yi...>]

 >Naturally, it would be nice to be able to enter a LIST of users (even 
if only
>as webmaster and not via the admin functions) with individual 
passwords, but
>for now just one -- with USER powers only -- will suffice.

Willie L's response (thanks for responding so quickly):

"Maybe using PhpLib authentication this should be possible.

I adapted PhpWiki to authenticate users through the database created by 
PhpLibi.
Is it useful for you?"

Thank you, Willie, but perhaps I should have put glowing neon lights 
and dancing animated gifs around the word "simple" in my request. 
Unlike (apparently) most of you in this list, I am not (yet) a coder. 
[I did figure out what to add (some missing code) to line 201 of 
index.php in order to get my phpwiki 1.3.3 to work, but that was about 
the extent of my current "expertise" with php.]

So if anyone can tell me "add these lines here to create a user and 
password" or something like that, it would reach me on my current level 
of non-expertise. It just seems so basic, not so very different from 
what the application is already doing, that I thought it would be 
pretty simple to add at least one user... the level I am looking for is 
more secure than BOGO (can anyone tell me what value that BOGO feature 
has, anyway?) but grants less than full admin powers.

It would be a nice feature for this (or any) wiki to have anyway. But 
if it can't be done in this application, I guess my only recourse would 
be to give the entire group the admin password and just hope they don't 
mess their wiki up too badly.

Thanks again to any and all who can offer help or suggestions on this.

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

Re: [Phpwiki-talk] Simple security for phpwiki?

[Willie D. L. <wd...@ic...>]

On Fri, 16 Aug 2002 xi...@yi... wrote:

>Naturally, it would be nice to be able to enter a LIST of users (even if only
>as webmaster and not via the admin functions) with individual passwords, but
>for now just one -- with USER powers only -- will suffice.

Maybe using PhpLib authentication this should be possible.

I adapted PhpWiki to authenticate users through the database created by PhpLibi.
Is it useful for you?

Kind regards,
Willie Leiva

[Phpwiki-talk] Simple security for phpwiki?

[<xi...@yi...>]

Hi, I am pretty new to this, but am quite impressed with the power and 
possibilies of phpwiki (1.3.3) from what I have seen thus far. My 
question is fairly simple, and perhaps a way to do this already exists 
within the original 1.3.3 package:

What I want is either an (existing) way or a (simple) hack to create -- 
even if I must do it through editing the source files -- at least one 
user name and password OTHER than admin. Here's my concern:

I am getting ready to deploy some wikis to groups who want ONLY the 
allowed group members to be able to use the "edit this page" function. 
(They are concerned about others defacing the site.) They may wish for 
me to be the admin, or they may designate a group member for this role, 
but they do NOT want the other members to have admin powers -- just the 
ability to edit the pages, i.e. contribute new posts.

Now, if I understand it correctly, the BOGO login is pretty useless, as 
anyone can enter any wiki word to sign in, with no authentication 
(password) required -- which means that an "outsider" could spoof any 
username they chose.

And on the other end of the scale, full admin privileges (such as 
locking and removing pages) would not be appropriate for most of the 
group. Some other wikis do offer online registration of users (much 
like a message forum, it appears, complete with separate passwords, 
etc.), but we don't need anything that elaborate: Just ONE sign-in name 
and password which is only issued to the group, and which the admin (or 
webmaster, if there is no way to change this except through directly 
editing the source files) can change if it becomes necessary.

So, if any of you can point the way to solving this, I will greatly 
appreciate it. Naturally, it would be nice to be able to enter a LIST 
of users (even if only as webmaster and not via the admin functions) 
with individual passwords, but for now just one -- with USER powers 
only -- will suffice.

Thank you in advance for your help with this!      
       

-----------------------------------------------------
http://eo.yifan.net
Free POP3/Web Email, File Manager, Calendar and Address Book

[Phpwiki-talk] Re: Two domains, same phpwiki page

[Matt P. <pi...@kp...>]

I think this is what I am looking for.
Thanks, I will try it out.
Matt 

Joby Walker writes: 

> Line 162 of phpwiki/lib/config.php in 1.3.3 (as I have it) sets the 
> definition of SERVER_URL if it is not set already. 
> 
> I would set up a if/else statement in phpwiki/index.php to define 
> SERVER_URL based off of the IP address or hostname of the client: 
> 
> if ( <regexp to determine if internal> ) {
> 	define('SERVER_URL', 'int.x.com');
> } else {
> 	define('SERVER_URL', 'x.com');
> } 
> 
> jbw 
> 
> 
> Matt Pieklik wrote:
>> I have run into a situation where I have one webserver serving a private 
>> network and the internet and serving up the same web pages.  The problem 
>> is, the private network has a different domain name than the public side. 
>>  Lets say the public net is x.com and the private is int.x.com.
>> I have a link for a file on the webserver,
>> [OP AMPS for Everyone Book  | 
>> https:/internal/reference/guides/electronics/opamp/OpAmpsForEveryone.pdf]
>> I think this is a terrible way to do things, /internal/references... is 
>> the path to the file, not the machine name...I had use https: to force 
>> the SSL protocol, otherwise it would try http, which is being blocked.
>> The problem is with this kludge, it only seems to work with IE browsers.  
>> Mozilla interprets "/internal" as a machine name and tries to find a 
>> machine by that name.
>> I can't use the the machine name in the URL because this page is being 
>> accessed by both internal and external hosts, thus the machine has two 
>> different domain names.
>> Anyone have any suggestions on the proper or better way of doing this?
>> TIA,
>> Matt 
>> 
>> 
>> -------------------------------------------------------
>> This sf.net email is sponsored by: OSDN - Tired of that same old
>> cell phone?  Get a new here for FREE!
>> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>> _______________________________________________
>> Phpwiki-talk mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>  
> 
>  
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk