Loading...
 
Skip to main content

Development

Forum List Topic List

Forums » Development » Tiki 1.8.2 and URLs
 
Thread actions
Print this page
  • Print all pages

    • Tiki 1.8.2 and URLs

    Posted by actinic posts: 14 ☆ ☆ ☆

    I'm noticing some interesting behaviour in my tiki since I upgraded to 1.8.2. I'm not sure if it's related to the new cross site scripting checking or not. The things I'm noticing are:

    1. If I edit templates online within tiki (say header.tpl), Javascript tags linking to the tikilib javascript library get stripped out when you save the template (to workaround this I've disabled editing templates within tiki for the time being).

    2. I have some custom php that I wrote that integrates with tiki. It makes use of the tikilib for get information from the file galleries. It's output is an echo'ed HTML page (frameset) with content and links. In tiki 1.8.2, the src tags for the frameset get stripped out in the output in my browser.

    Both of these worked in 1.8.1 obviously. Does anyone have any tips on how to track down the source of these problems or have first hand knowledge of what's causing it and how to correct it?

    Reads: 2426
    Posted by actinic posts: 14 ☆ ☆ ☆
    Okay, I've figued out my problem for item 2. For some reason the array version of preg_replace won't work. It matches the expressions, but then substitutes an empty string instead of the corresponding replacement string. Calling preg_replace with strings works so I'm using that. I don't understand why it's suddenly become a problem with 1.8.2 where it was working nicely under 1.8.1. I've made no other changes to my setup other than the tiki upgrade and I've seen the problem on two different systems (one upgraded via tarball, the other via rpm).
    Posted by ewan posts: 17 ☆ ☆ ☆

    > actinic:

    Okay, I've figued out my problem for item 2. For some reason the array version of preg_replace won't work. It matches the expressions, but then substitutes an empty string instead of the corresponding replacement string. Calling preg_replace with strings works so I'm using that. I don't understand why it's suddenly become a problem with 1.8.2 where it was working nicely under 1.8.1. I've made no other changes to my setup other than the tiki upgrade and I've seen the problem on two different systems (one upgraded via tarball, the other via rpm).


    hya,

    I had the same problem when upgrading from 1.8 to 1.8.2 - no solution i'm afraid.

    ewan


    Posted by ewan posts: 17 ☆ ☆ ☆

    > actinic:

    Okay, I've figued out my problem for item 2. For some reason the array version of preg_replace won't work. It matches the expressions, but then substitutes an empty string instead of the corresponding replacement string. Calling preg_replace with strings works so I'm using that. I don't understand why it's suddenly become a problem with 1.8.2 where it was working nicely under 1.8.1. I've made no other changes to my setup other than the tiki upgrade and I've seen the problem on two different systems (one upgraded via tarball, the other via rpm).


    hya,

    I had the same problem when upgrading from 1.8 to 1.8.2 - no solution i'm afraid.

    ewan


    Posted by Damian Parker posts: 2881 ☆ ☆ ☆ ☆ ☆ United Kingdom

    Hello!

    Yes all nasty script, object, embed, and others get removed now. Maybe in 1.8.3 we can have some per form checkbox that requires activation before submitting, certainly it wouldnt be a global option!

    Posted by actinic posts: 14 ☆ ☆ ☆

    > Damian:
    > Yes all nasty script, object, embed, and others get removed now. Maybe in 1.8.3 we can have some per form checkbox that requires activation before submitting, certainly it wouldnt be a global option!

    The problem with this is that the default tiki templates make use of Javascript in good and useful ways (expanding items on the application menu for example). Maybe the stripping of tags needs to be more intelligent, only allowing tags with known "good" attribute values.

    Posted by Damian Parker posts: 2881 ☆ ☆ ☆ ☆ ☆ United Kingdom

    > actinic:
    > > Damian:
    > > Yes all nasty script, object, embed, and others get removed now. Maybe in 1.8.3 we can have some per form checkbox that requires activation before submitting, certainly it wouldnt be a global option!
    >
    > The problem with this is that the default tiki templates make use of Javascript in good and useful ways (expanding items on the application menu for example). Maybe the stripping of tags needs to be more intelligent, only allowing tags with known "good" attribute values.
    >

    The "cleaner" only affects the javascript and things that you submit through the tiki interface, those JS bits that are called from the tpl files are not affected.

    Javascript is such a huge language, you would have a hard time defining whats good there and what isnt.

    Damian

    Posted by actinic posts: 14 ☆ ☆ ☆

    > Damian:
    > The "cleaner" only affects the javascript and things that you submit through the tiki interface, those JS bits that are called from the tpl files are not affected.

    Yes, that's what I meant. An example is, I had online template editing enabled in tiki. After I upgraded to 1.8.2 I went and made a simple modification header.tpl, saved it, and suddenly the application menu can't be expanded or collapsed because the javascript tag is stripped. The online template editing becomes very difficult to use with confidence you can't easily verify what it's stripped out (although in my example you could).

    > Javascript is such a huge language, you would have a hard time defining whats good there and what isnt.

    Yes, it would only work sensibly for script tags with source attributes (like in header.tpl). If the source of the script is known and good, allow it.


    Posted by Damian Parker posts: 2881 ☆ ☆ ☆ ☆ ☆ United Kingdom

    > actinic:
    > > Damian:
    > > The "cleaner" only affects the javascript and things that you submit through the tiki interface, those JS bits that are called from the tpl files are not affected.
    >
    > Yes, that's what I meant. An example is, I had online template editing enabled in tiki. After I upgraded to 1.8.2 I went and made a simple modification header.tpl, saved it, and suddenly the application menu can't be expanded or collapsed because the javascript tag is stripped. The online template editing becomes very difficult to use with confidence you can't easily verify what it's stripped out (although in my example you could).
    >
    > > Javascript is such a huge language, you would have a hard time defining whats good there and what isnt.
    >
    > Yes, it would only work sensibly for script tags with source attributes (like in header.tpl). If the source of the script is known and good, allow it.
    >
    >
    >

    For now Id recommend either SSH access to site site and trusty vi, or edit through FTP access.

    Damian


    Posted by actinic posts: 14 ☆ ☆ ☆

    > Damian:
    > Yes all nasty script, object, embed, and others get removed now. Maybe in 1.8.3 we can have some per form checkbox that requires activation before submitting, certainly it wouldnt be a global option!

    The problem with this is that the default tiki templates make use of Javascript in good and useful ways (expanding items on the application menu for example). Maybe the stripping of tags needs to be more intelligent, only allowing tags with known "good" attribute values.

    Posted by Damian Parker posts: 2881 ☆ ☆ ☆ ☆ ☆ United Kingdom

    > actinic:
    > > Damian:
    > > Yes all nasty script, object, embed, and others get removed now. Maybe in 1.8.3 we can have some per form checkbox that requires activation before submitting, certainly it wouldnt be a global option!
    >
    > The problem with this is that the default tiki templates make use of Javascript in good and useful ways (expanding items on the application menu for example). Maybe the stripping of tags needs to be more intelligent, only allowing tags with known "good" attribute values.
    >

    The "cleaner" only affects the javascript and things that you submit through the tiki interface, those JS bits that are called from the tpl files are not affected.

    Javascript is such a huge language, you would have a hard time defining whats good there and what isnt.

    Damian

    Posted by actinic posts: 14 ☆ ☆ ☆

    > Damian:
    > The "cleaner" only affects the javascript and things that you submit through the tiki interface, those JS bits that are called from the tpl files are not affected.

    Yes, that's what I meant. An example is, I had online template editing enabled in tiki. After I upgraded to 1.8.2 I went and made a simple modification header.tpl, saved it, and suddenly the application menu can't be expanded or collapsed because the javascript tag is stripped. The online template editing becomes very difficult to use with confidence you can't easily verify what it's stripped out (although in my example you could).

    > Javascript is such a huge language, you would have a hard time defining whats good there and what isnt.

    Yes, it would only work sensibly for script tags with source attributes (like in header.tpl). If the source of the script is known and good, allow it.


    Posted by Damian Parker posts: 2881 ☆ ☆ ☆ ☆ ☆ United Kingdom

    > actinic:
    > > Damian:
    > > The "cleaner" only affects the javascript and things that you submit through the tiki interface, those JS bits that are called from the tpl files are not affected.
    >
    > Yes, that's what I meant. An example is, I had online template editing enabled in tiki. After I upgraded to 1.8.2 I went and made a simple modification header.tpl, saved it, and suddenly the application menu can't be expanded or collapsed because the javascript tag is stripped. The online template editing becomes very difficult to use with confidence you can't easily verify what it's stripped out (although in my example you could).
    >
    > > Javascript is such a huge language, you would have a hard time defining whats good there and what isnt.
    >
    > Yes, it would only work sensibly for script tags with source attributes (like in header.tpl). If the source of the script is known and good, allow it.
    >
    >
    >

    For now Id recommend either SSH access to site site and trusty vi, or edit through FTP access.

    Damian