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@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 'Calendar.yyyymmdd'. 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. _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users