Loading...
 
Development

Development


Tiki 1.8.2 and URLs

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?

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).
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


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


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!

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.

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

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.


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


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.

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

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.


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


Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting