[pmwiki-users] UserAuth2 and WikiCalendar problem

IchBin weconsultants at gmail.com
Tue Jun 5 13:02:40 CDT 2007

IchBin wrote:
> ThomasP wrote:
>> On Thu, May 31, 2007 02:12, IchBin wrote:
>>> IchBin wrote:
>>>> I am fooling around with WikiCalendar since I can not get any response
>>>> from the author of Logbook. It is not working, for me, but then that is
>>>> another post I posted here and to his personal email address.
>>>> Anyway, a user with UserAuth2 security of read\write "ed_Calendar.*"
>>>> access has no problem editing a day when picking it from the visual
>>>> calendar.
>>>> There is a problem when they use the "Story form markup (:wikilogbox:)"
>>>> to post to the calendar. The error looks like this for say adding a
>>>> story on 05/29/2007:
>>>> Calendar /
>>>> 20070529
>>>> Insufficient privileges to perform action
>>>> The files are kept on disk in this format: 'Calendar.YYYYMMDD'. So this
>>>> page would be: Calendar.20070529. It does not seem to matter if the
>>>> Calendar.date exists or needs to be created. I just get the security
>>>> error.
>>>> The current calendar files I have are:
>>>> Calendar.Calendar
>>>> Calendar.GroupHeader
>>>> Calendar.RecentChanges
>>>> Calendar.20070528
>>>> Calendar.20070530
>>>> Calendar.20070530
>>>> Just a quick idea: I guess there must be an intermediary file that does
>>>> not conform to the Calendar naming convention that is created\destroyed
>>>> (temp file) in the process of posting a 'Story message' to the calendar.
>>>>   I'll take a peek.
>>> Looking at the logic in UserAuth2.php in function
>>> TryAccessingPage($pagename, $level) It is passing this:
>>> $pagename = Calendar/20070429
>>> $level = edit
>>> But get caught on this:
>>> if ($UserInstanceVars->isAuthenticated())
>>> even though I set the security rule for the user to: 'ed_*.*' and I am
>>> signed in... Should be OK.
>> The auth module will always expect normalized pagenames, i.e. of the form
>> Group.Page
>> As it will be difficult pmwiki wide to make this sure, it is probably
>> easier if you add the line
>> str_replace('/', '.', $pagename)
>> as first line in the UserAuth2() function. This will resolve at least the
>> above problem.
>> Thomas
>>> --
>>> Thanks in Advance...           http://weconsulting.org
>>> IchBin, Philadelphia, Pa, USA http://ichbinquotations.weconsulting.org
>>> ______________________________________________________________________
>>> 'If there is one, Knowledge is the "Fountain of Youth"'
>>> -William E. Taylor, Regular Guy (1952-)
>>> _______________________________________________
>>> pmwiki-users mailing list
>>> pmwiki-users at pmichaud.com
>>> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
> Thanks for the reply Thomas. Still having security error after adding 
> line of code to UserAuth2($pagename, $level, $authprompt=true).
> function UserAuth2($pagename, $level, $authprompt=true) {
>    // If called with $authprompt==true, the function is expected
>    // to produce either the specified page to the client or
>    // print the login page. If called with $authprompt==false, the
>    // caller just wants to know whether the current user has the
>    // permission to access the specified page at the given level.
>    // Still, the pmwiki engine demands the page being returned on
>    // success, since it needs the time stamps and other fields.
>    // Fix to normalize the page url to use '/' and not '.'
>    str_replace('/', '.', $pagename);
>    if ($authprompt)
>      return TryAccessingPage($pagename, $level);
>    else {
>      if (HasCurrentUserPerm($pagename, $level)) {
>        return ua2AssemblePageToReturn($pagename);
>      }
>    }
>    return false;
> }

Not sure if I mentioned this Thomas but as an 'admin' user there is no 
security problem posting a formatted item to the WikiCalendar using the 
(:wikilogbox:) markup. Guess this would rule out any non normalized page 
url. The problem is only with a regular user even though they have a 
'ed_Calendar.*' rule. I mean the format of the calendar days is 

I am trying to find a PHP debugger that works or has the same behavior 
as a Java debugger. Once I do I think it will be much easier to figure 
out. PHP IDE's seem to be half-baked and don't want to put real money 
out for Zend over sized all in-compassing tools. They did enough damage 
with the Eclipse open source PDT plugin to a point where an IBM'er added 
support for Xdebug on his own time, which is REALLY open source but I 
guess that is another conversation for somewhere else.

More information about the pmwiki-users mailing list