Revision [1763]

This is an old revision of WikkaBugsResolved made by JsnX on 2004-10-09 04:55:21.

 

Resolved bugs


For open Bugs/Issues look at WikkaBugs.
 

Password change problem

If spaces are entered on passwords, it does not works and no feedback is given to users. I tried on the "Change Password" part, not on the new user registration. --DavidCollantes

Simple fix:
Around line 96 in actions/usersettings.php change this:
        <?php
        if (isset($error))
        {
            print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
        }
        ?>

to this:
        <?php
        if (isset($passerror))
        {
            print("<tr><td></td><td><div class=\"error\">".$this->Format($passerror)."</div></td></tr>\n");
        }
        ?>

-- JavaWoman

Yup. Thanks for pointing this out. Fixed in Wikka 1.1.5.4 and above. -- JsnX


Security bug in UserSettings (minor)
[Moved this back up again and edited since as of 1.1.5.3 it's only half fixed: only one of the assignments has been changed into a comparison operator. Sorry, I should have noticed before]
The file actions/usersettings.php contains a function for a logged in user to change their password; looking at the code, the apparent intention is to verify the user's current password before accepting the new one:
Line 35:
<?php ...
    else if (($user["password"] = md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"]))
?>

Unfortunately, this test always succeeds since it does an assignment instead of a comparison - and since the boolean operator is OR (
) it doesn't matter if the second term is (now) a comparison: just the single assignment in the first term will make it always evaluate as TRUE. This presents a security risk in (semi) public situations where someone might "take over" a logged-in user's account. The code should be corrected as:
<?php ...
    else if (($user["password"] == md5($_POST["oldpass"])) || ($user["password"] == $_POST["oldpass"]))
?>

-- JavaWoman

Fixed in Wikka 1.1.5.4 and above. Thanks for pointing this out. -- JsnX

Code formatters and smart titles
Something dodgy has been done to this site's header.php. The code to extract document titles from the downloaded version is MUCH different from what you are showing here. Take a look at the document titles on HtmlAreaEditing and GmBowen. That's code in there! What's going on? This issue has been addressed in 1.1.5.1 via Mod040fSmartPageTitles. However the regex pattern needs to refined to avoid code samples (e.g. GmBowen)

The issue of code formatters has been adressed in 1.1.5.3 -- DarTar


XHTML not valid
Also in actions/usersettings.php: the state for "on" checkboxes is generated as 'checked'; to be valid XHTML such a boolean attribuet needs to be written as 'checked="checked"'.
JavaWoman

Both bugs are now fixed, and will be in the next release. Thanks! - JsnX



I've discovered a weird sort of bug. When I attempt to create a page whose name contains the string CategoriesExplained, I get a 403 error on wikka.php (no re-writing enabled) when I attempt to preview or store this information. I was trying to create a page named WikiCategoriesExplained on my site (attempting to replace the irritatingly named WikiCategory). I've managed to replicate this bug on this site (click here then click Preview. -- Sam
It's not really a Wikka bug. Edit the .htaccess in your root Wikka directory. Remove the word sex from within the line that starts with 'SetEnvIfNoCase'. I've taken care of this for the next release. - JsnX
  • ACLs bug (reproduced here - SdfdsfaSdasd): when you change the read access to "!*" (stop all), the only way to revert this back to "*" is:
    • Give rights to a new user (so ACL for read access says "ban all, but allow access for SdfdsfaSdasd")
    • Save ACL
    • Edit ACL, deleting SdfdsfaSdasd and the exclamation mark
  • Another ACL bug: you can't changed ownership of a page to Nobody. This may be because of the Not Null aspect of the tables, but frankly, it's quite irritating! I have removed this option from my own installation of acl.php.


2) The WantedPages page uses the linking_to query-string. The character preceding this should be a "?" if URL re-writing is enabled, but a "&" if not. For example, if I use the default wikka.php?wikka=WantedPages?linking_to=TestMe, this will attempt to create a new page. This bug may be already addressed at Mod032bModRewrite, but frankly, I can't understand it.

  • the new tab conversion in the formatters/wakka.php replaces not only four successive space characters with a tab, but any whitespace which a tab itself used to be one. replace the metachar "\s" in the square brackets with a real space like this:
$text = preg_replace("/\n[ ]{4}/", "\n\t", $text);

then program listings with levels indented four and more times will be rendered correctly again.
    • Yup. That's originally how I had it, but then mucked it up for some reason. Resolved in 1.1.4.1. Thanks for pointing it out. -- JsnX

  • Homepage is not CSS valid -- Fixed.
  • Mod_rewrite : I'm waiting for 1.1.4, but This is a bug I found at 1.1.0 : every Rewrite directive in each .htaccess file should be enclosed in <IfModule mod_rewrite.c>, </IfModule>; because if you just add IfModule in ./.htaccess, no image, no js, no css will be downloaded because the server will send an http 500 error. So, what you are saying is that the .htaccess file in the root directory is okay, but I need to add the Ifmodule conditional to the other .htaccess files in the css, image, and wikiedit2 directories as follows? ...
Yes! (You can try to disable mod_rewrite by commenting the corresponding LoadModule in httpd.conf)
More about Mod_rewrite : take a look at FaviconDotIco and RobotsDotTxt [DotMG]
<IfModule mod_rewrite.c>
RewriteEngine off
</IfModule>


Version Wikka Wakka Wiki 1.0.4:
  • External links 'eat' the closing bracket: (see http://www.cnn.com) [MarkHissinkMuller]
    • Acknowledged. -- JsnX 5/27/04 ..... Fixed in Wikka 1.0.5. -- JsnX 5/29/04


bug in redesigned acl-handling?


am i wrong or does the $wakka->hasaccess routine (v. 1.1.3) only check the user-rights against the present page, regardless if the parameter $tag is set or not? i haven't had a closer look, but as i understood, the check against $this->acls[$privilege."_acl"] only returns the right value, if $tag == $this->tag and else should be passed over to the loadacl-function as wakka did. -- DreckFehler

  • Fixed in 1.1.3.1 and above. -- JsnX



formatters don't care about diff-tags

none of the formatters which are triggered by the %%double-percent tag%% observes the tags that are inserted by the diff-engine, although the main-formatter wakka.php delegates all rendering to these formatters. an example is shown here:

http://wikka.jsnx.com/FeedbackAction/diff?a=828&b=792

just search for "pound" or "++" on that page.

in most cases this issue can be solved by a simple str_replace. an exception is the php-highlighter. see the link below for a solution.

but fixing that problem rises another! i'm unhappy with the "++" tag used by the diff-engine to mark deletions. the double-plus is also the increment operator of php (and other languages) and can't be distiguished from the diff-tags. this problem is addressed in the following sample code too:

http://mindwiki.de/wikka_bug_-_formatters_to_care_about_diff-engine/diff?a=387&b=384

that page might be an example what this bugfix is good for, but it also shows up the limits. naturally the sample-code contains those diff-tags which it is dealing with. that obviously screws up the diff-engine again. so take care not only to paste-n-copy the code snippets from the link above ;)
  • Fixed in 1.1.3.3 and above. -- JsnX


CategoryDevelopment
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki