Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.4
    • Fix Version/s: 2.4
    • Component/s: Tool Wiki
    • Labels:
      None

      Description

      There's a few issues with internal links in Wiki not functioning properly.

      It's a bit long to reproduce, but follow these steps and you'll see the issue:

      Launch author and drop a wiki activity. Add a second page and create a link in it to the Main page (using the wiki linking in the ckeditor).

      From the main page create a link to the second page.

      Save.

      Create a lesson with this sequence

      Now go to learner add a third page and put links in it to go to Main and second page. Save and you'll see that the links go to "void(0)". But if you refresh the links work OK then.

      Go back to the main page and create a link to the third page and save... you see that now the links aren't working properly... the second link now links to:

      <a href="javascript:changeWikiPage(" second="">Second page</a>

      Which returns a javascript error. Even if you refresh the link it's now broken.

        Activity

        Hide
        marcin Marcin Cieslak added a comment -
        All steps to weren't necessary to reproduce. For error to appear it was enough to edit a Wiki page with an existing link to another page.
        There was a problem with quotes within a javascript method call, but it's now fixed.
        Show
        marcin Marcin Cieslak added a comment - All steps to weren't necessary to reproduce. For error to appear it was enough to edit a Wiki page with an existing link to another page. There was a problem with quotes within a javascript method call, but it's now fixed.
        Hide
        ernieg Ernie Ghiglione added a comment -
        Marcin, I think we still have some issues. I made a little demo video here:

        http://youtu.be/3EhqG8TWVfY
        Show
        ernieg Ernie Ghiglione added a comment - Marcin, I think we still have some issues. I made a little demo video here: http://youtu.be/3EhqG8TWVfY
        Hide
        marcin Marcin Cieslak added a comment -
        Problem with void(0) links is a completely different issue. It is not limited only to newly added links but all links after a page has been edited or added.
        It does not appear in Firefox, but can be observed in Chrome and obviously Safari too.

        When a page is edited in CKEditor and saved, javascript console shows
        "Refused to execute a JavaScript script. Source code of script found within request"
        It is a security measure preventing code coming from HTTP response to be executed. It prevents malicious code injection:

        http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html
        Reflective XSS Protection

        It can not be easily tricked, so the only simple solution seems to be refreshing Wiki page right after it was edited, so browser understands the code comes from content already existing on a server, not a HTTP response.
        This was implemented for Learner. Automatic refreshing for Author is coming shortly.
        For user it looks like the page flicks after editing page, but hopefully it is not very uncomfortable.

        Also a problem with loading CKEditor in IE was observed, but it needs checking.
        Show
        marcin Marcin Cieslak added a comment - Problem with void(0) links is a completely different issue. It is not limited only to newly added links but all links after a page has been edited or added. It does not appear in Firefox, but can be observed in Chrome and obviously Safari too. When a page is edited in CKEditor and saved, javascript console shows "Refused to execute a JavaScript script. Source code of script found within request" It is a security measure preventing code coming from HTTP response to be executed. It prevents malicious code injection: http://blog.chromium.org/2010/01/security-in-depth-new-security-features.html Reflective XSS Protection It can not be easily tricked, so the only simple solution seems to be refreshing Wiki page right after it was edited, so browser understands the code comes from content already existing on a server, not a HTTP response. This was implemented for Learner. Automatic refreshing for Author is coming shortly. For user it looks like the page flicks after editing page, but hopefully it is not very uncomfortable. Also a problem with loading CKEditor in IE was observed, but it needs checking.
        Hide
        marcin Marcin Cieslak added a comment -
        Attempt to solve the problem by refreshing the page became too heavy as it would be required even when user goes from one Wiki page to another.

        The whole issue was that "authoringForm" has fields like "wikiBody" and "newPageWikiBody" containing Wiki page content. It contains javascript code, like
        href="javascript:changeWikiPage('view')"
        Browsers like Chrome and Safari detects this code in request and that it is reflected by the server when displaying the added/edited/viewed Wiki page. It is considered a XSS attack and becomes blocked from execution.

        There is no easy workaround this, as many security holes were detected and eliminated.

        The solution is to replace "javascript" word with another token (here: JAVASCRIPTREPLACE) before submitting the form and the replace it back on server side. This way the submitted content does not contain correct javascript code and is different to content reflected by server, so the it passes XSS check.
        The above issue is solved.

        A problem with IE and CKEditor still remains and will be investigated soon.
        Show
        marcin Marcin Cieslak added a comment - Attempt to solve the problem by refreshing the page became too heavy as it would be required even when user goes from one Wiki page to another. The whole issue was that "authoringForm" has fields like "wikiBody" and "newPageWikiBody" containing Wiki page content. It contains javascript code, like href="javascript:changeWikiPage('view')" Browsers like Chrome and Safari detects this code in request and that it is reflected by the server when displaying the added/edited/viewed Wiki page. It is considered a XSS attack and becomes blocked from execution. There is no easy workaround this, as many security holes were detected and eliminated. The solution is to replace "javascript" word with another token (here: JAVASCRIPTREPLACE) before submitting the form and the replace it back on server side. This way the submitted content does not contain correct javascript code and is different to content reflected by server, so the it passes XSS check. The above issue is solved. A problem with IE and CKEditor still remains and will be investigated soon.
        Hide
        marcin Marcin Cieslak added a comment -
        Links are shown correctly in Wiki now.
        Other issues with CKEditor and IE are continued in separate JIRA LDEV-2831.
        Show
        marcin Marcin Cieslak added a comment - Links are shown correctly in Wiki now. Other issues with CKEditor and IE are continued in separate JIRA LDEV-2831 .
        Hide
        ernieg Ernie Ghiglione added a comment -
        Tested and closed
        Show
        ernieg Ernie Ghiglione added a comment - Tested and closed

          People

          • Assignee:
            marcin Marcin Cieslak
            Reporter:
            ernieg Ernie Ghiglione
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development