2 Mar
2010
2 Mar
'10
5:01 p.m.
Greetings
On my wiki using swedish characters for xwiki page titles give ugly but
working entries in all panels, e.g. "Backlinks" "Recent modifications"
and "My
recent modifications"
An example is having:
"Startsidor för våra intresseområden"
...instead of the correct:
"Startsidor för våra intresseområden"
Another example is putting thiss wiki code on top of a page:
= header that <look ugly> here =
The script responsible for for the texts in the panels is as follow:
<span class="panelitem">
<a href="$rdoc.getURL('view')">
$xwiki.getXMLEncoded($rdoc.displayTitle)
</a></span>
I've noticed that changing the third line into only $rdoc.displayTitle will
produce a nice looking entry, and $rdoc is set via
#set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
have seen, it only breaks things.
-Joel
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Grad. student) Joel Forsberg
KTH Kemisk Teknologi
Teknikringen 41B
100 44 Stockholm
Work +46 8 7908252
e-mail: joelfo(a)kth.se
2 Mar
2 Mar
6:25 p.m.
On 03/02/2010 05:01 PM, Joel Forsberg wrote:
Greetings
On my wiki using swedish characters for xwiki page titles give ugly but
working entries in all panels, e.g. "Backlinks" "Recent
modifications" and "My
recent modifications"
An example is having:
"Startsidor för våra intresseområden"
...instead of the correct:
"Startsidor för våra intresseområden"
Another example is putting thiss wiki code on top of a page:
= header that<look ugly> here =
The script responsible for for the texts in the panels is as follow:
<span class="panelitem">
<a href="$rdoc.getURL('view')">
$xwiki.getXMLEncoded($rdoc.displayTitle)
</a></span>
I've noticed that changing the third line into only $rdoc.displayTitle will
produce a nice looking entry, and $rdoc is set via
#set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
have seen, it only breaks things.
This is not caused by getXMLEncoded, it merely makes the problem
visible. This method must be used in order to prevent other problems:
Invalid XML, broken layout, XSS...
The problem is that the code inside getDisplayTitle wrongly uses a XML
escaping option.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
8:20 p.m.
New subject: [xwiki-users] What is $xwiki.getXMLEncoded()'s purpose in url names?
On Tue, Mar 2, 2010 at 18:25, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 03/02/2010 05:01 PM, Joel Forsberg wrote:
No, this is valid because the job of $rdoc.displayTitle is to produce
xhtml content and theses are valid XML escapes. So you don't need to
use getXMLEncoded because any xml content is already properly escaped
(in xwiki/2.0 syntax).
When you want a plain text version of the title you should use
$rdoc.getRenderedTitle("plain/1.0").
Greetings
On my wiki using swedish characters for xwiki page titles give ugly but
working entries in all panels, e.g. "Backlinks" "Recent
modifications" and "My
recent modifications"
An example is having:
"Startsidor för våra intresseområden"
...instead of the correct:
"Startsidor för våra intresseområden"
Another example is putting thiss wiki code on top of a page:
= header that<look ugly> here =
The script responsible for for the texts in the panels is as follow:
<span class="panelitem">
<a href="$rdoc.getURL('view')">
$xwiki.getXMLEncoded($rdoc.displayTitle)
</a></span>
I've noticed that changing the third line into only $rdoc.displayTitle will
produce a nice looking entry, and $rdoc is set via
#set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
have seen, it only breaks things.
This is not caused by getXMLEncoded, it merely makes the problem
visible. This method must be used in order to prevent other problems:
Invalid XML, broken layout, XSS...
The problem is that the code inside getDisplayTitle wrongly uses a XML
escaping option. --
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
--
Thomas Mortagne
3 Mar
3 Mar
11:15 a.m.
New subject: [xwiki-users] What is $xwiki.getXMLEncoded()'s purpose in url names?
Thanks Thomas
I made a JIRA entry against the Panels Application, and a trivial patch to fix
it. It's my first, so It'll be exciting to see what happens. :)
http://jira.xwiki.org/jira/secure/ManageAttachments.jspa?id=29978
-Joel Forsberg
On Tuesday 02 March 2010 20:20:01 Thomas Mortagne wrote:
On Tue, Mar 2, 2010 at 18:25, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
On 03/02/2010 05:01 PM, Joel Forsberg wrote:
No, this is valid because the job of $rdoc.displayTitle is to produce
xhtml content and theses are valid XML escapes. So you don't need to
use getXMLEncoded because any xml content is already properly escaped
(in xwiki/2.0 syntax).
When you want a plain text version of the title you should use
$rdoc.getRenderedTitle("plain/1.0").
Greetings
On my wiki using swedish characters for xwiki page titles give ugly but
working entries in all panels, e.g. "Backlinks" "Recent
modifications"
and "My recent modifications"
An example is having:
"Startsidor för våra intresseområden"
...instead of the correct:
"Startsidor för våra intresseområden"
Another example is putting thiss wiki code on top of a page:
= header that<look ugly> here =
The script responsible for for the texts in the panels is as follow:
<span class="panelitem">
<a href="$rdoc.getURL('view')">
$xwiki.getXMLEncoded($rdoc.displayTitle)
</a></span>
I've noticed that changing the third line into only $rdoc.displayTitle
will produce a nice looking entry, and $rdoc is set via
#set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
Now, can anyone see a purpose of using getXMLEncoded() for this? As far
as I have seen, it only breaks things.
This is not caused by getXMLEncoded, it merely makes the problem
visible. This method must be used in order to prevent other problems:
Invalid XML, broken layout, XSS...
The problem is that the code inside getDisplayTitle wrongly uses a XML
escaping option. --
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
5 Mar
5 Mar
4:58 a.m.
On 03/02/2010 08:20 PM, Thomas Mortagne wrote:
On Tue, Mar 2, 2010 at 18:25, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
Where does it say that it should produce xhtml content?
Assuming that it should produce xhtml, the behavior is inconsistent. If
the title is placed in the document.title field, then it returns
characters; if it is placed in the first heading, it returns escapes. If
we use wiki syntax in the document.title, we get back wiki syntax; if we
use wiki syntax in the first heading, we get back HTML. That is totally
inconsistent and confusing.
This is an API design problem that should be discussed further on the
dev list.
Going back to this specific problem, I think that it should be solved by
using the plaintext output syntax, since inside a panel we're not
interested in formatting or other markup inside the title, just the
textual content.
On 03/02/2010 05:01 PM, Joel Forsberg wrote:
No, this is valid because the job of $rdoc.displayTitle is to produce
xhtml content and theses are valid XML escapes.
Greetings
On my wiki using swedish characters for xwiki page titles give ugly but
working entries in all panels, e.g. "Backlinks" "Recent
modifications" and "My
recent modifications"
An example is having:
"Startsidor för våra intresseområden"
...instead of the correct:
"Startsidor för våra intresseområden"
Another example is putting thiss wiki code on top of a page:
= header that<look ugly> here =
The script responsible for for the texts in the panels is as follow:
<span class="panelitem">
<a href="$rdoc.getURL('view')">
$xwiki.getXMLEncoded($rdoc.displayTitle)
</a></span>
I've noticed that changing the third line into only $rdoc.displayTitle will
produce a nice looking entry, and $rdoc is set via
#set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
have seen, it only breaks things.
This is not caused by getXMLEncoded, it merely makes the problem
visible. This method must be used in order to prevent other problems:
Invalid XML, broken layout, XSS...
The problem is that the code inside getDisplayTitle wrongly uses a XML
escaping option. So you don't need to
use getXMLEncoded because any xml content is already properly escaped
(in xwiki/2.0 syntax).
I need to use getXMLEncoded because the title doesn't always come from
the content.
When you want a plain text version of the title you
should use
$rdoc.getRenderedTitle("plain/1.0").
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
10:06 a.m.
New subject: [xwiki-users] What is $xwiki.getXMLEncoded()'s purpose in url names?
On Fri, Mar 5, 2010 at 04:58, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 03/02/2010 08:20 PM, Thomas Mortagne wrote:
public String getDisplayTitle(XWikiContext context)
{
return getRenderedTitle(Syntax.XHTML_1_0, context);
}
On Tue, Mar 2, 2010 at 18:25, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
Where does it say that it should produce xhtml content? On 03/02/2010 05:01 PM, Joel Forsberg wrote:
No, this is valid because the job of $rdoc.displayTitle is to produce
xhtml content and theses are valid XML escapes.
Greetings
On my wiki using swedish characters for xwiki page titles give ugly but
working entries in all panels, e.g. "Backlinks" "Recent
modifications" and "My
recent modifications"
An example is having:
"Startsidor för våra intresseområden"
...instead of the correct:
"Startsidor för våra intresseområden"
Another example is putting thiss wiki code on top of a page:
= header that<look ugly> here =
The script responsible for for the texts in the panels is as follow:
<span class="panelitem">
<a href="$rdoc.getURL('view')">
$xwiki.getXMLEncoded($rdoc.displayTitle)
</a></span>
I've noticed that changing the third line into only $rdoc.displayTitle will
produce a nice looking entry, and $rdoc is set via
#set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
have seen, it only breaks things.
This is not caused by getXMLEncoded, it merely makes the problem
visible. This method must be used in order to prevent other problems:
Invalid XML, broken layout, XSS...
The problem is that the code inside getDisplayTitle wrongly uses a XML
escaping option.
Assuming that it should produce xhtml, the behavior is inconsistent. If
the title is placed in the document.title field, then it returns
characters; if it is placed in the first heading, it returns escapes. If
we use wiki syntax in the document.title, we get back wiki syntax; if we
use wiki syntax in the first heading, we get back HTML. That is totally
inconsistent and confusing.
This is an API design problem that should be discussed further on the
dev list.
Going back to this specific problem, I think that it should be solved by
using the plaintext output syntax, since inside a panel we're not
interested in formatting or other markup inside the title, just the
textual content.
--
Thomas Mortagne
So you don't need to
use getXMLEncoded because any xml content is already properly escaped
(in xwiki/2.0 syntax).
I need to use getXMLEncoded because the title doesn't always come from
the content.
When you want a plain text version of the title
you should use
$rdoc.getRenderedTitle("plain/1.0").
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
10:40 a.m.
On 03/05/2010 10:06 AM, Thomas Mortagne wrote:
On Fri, Mar 5, 2010 at 04:58, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
I know that this is what it does, but why? The semantics of this method
changed over time. The method used (with 1.0 syntax) to return whatever
was in the title, interpreted but not rendered. So, if it did contain
html markup in it, then that was it. But the wiki markup wasn't rendered
into HTML. And it still behaves this way for the value placed in the
title field.
So, I don't agree with the behavior change and the inconsistency it creates.
On 03/02/2010 08:20 PM, Thomas Mortagne wrote:
public String getDisplayTitle(XWikiContext context)
{
return getRenderedTitle(Syntax.XHTML_1_0, context);
} On Tue, Mar 2, 2010 at 18:25, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
Where does it say that it should produce xhtml content? On 03/02/2010 05:01 PM, Joel Forsberg wrote:
>
> Greetings
>
> On my wiki using swedish characters for xwiki page titles give ugly but
> working entries in all panels, e.g. "Backlinks" "Recent
modifications" and "My
> recent modifications"
>
> An example is having:
> "Startsidor för våra intresseområden"
> ...instead of the correct:
> "Startsidor för våra intresseområden"
>
> Another example is putting thiss wiki code on top of a page:
> = header that<look ugly> here =
>
> The script responsible for for the texts in the panels is as follow:
>
> <span class="panelitem">
> <a href="$rdoc.getURL('view')">
> $xwiki.getXMLEncoded($rdoc.displayTitle)
> </a></span>
>
> I've noticed that changing the third line into only $rdoc.displayTitle will
> produce a nice looking entry, and $rdoc is set via
>
> #set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
>
> Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
> have seen, it only breaks things.
This is not caused by getXMLEncoded, it merely makes the problem
visible. This method must be used in order to prevent other problems:
Invalid XML, broken layout, XSS...
The problem is that the code inside getDisplayTitle wrongly uses a XML
escaping option.
No, this is valid because the job of $rdoc.displayTitle is to produce
xhtml content and theses are valid XML escapes. >
> Assuming that it should produce xhtml, the behavior is inconsistent. If
> the title is placed in the document.title field, then it returns
> characters; if it is placed in the first heading, it returns escapes. If
> we use wiki syntax in the document.title, we get back wiki syntax; if we
> use wiki syntax in the first heading, we get back HTML. That is totally
> inconsistent and confusing.
>
> This is an API design problem that should be discussed further on the
> dev list.
>
>
>
> Going back to this specific problem, I think that it should be solved by
> using the plaintext output syntax, since inside a panel we're not
> interested in formatting or other markup inside the title, just the
> textual content.
>
>> So you don't need to
>> use getXMLEncoded because any xml content is already properly escaped
>> (in xwiki/2.0 syntax).
>
> I need to use getXMLEncoded because the title doesn't always come from
> the content.
>
>> When you want a plain text version of the title you should use
>> $rdoc.getRenderedTitle("plain/1.0").
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
11:13 a.m.
New subject: [xwiki-users] What is $xwiki.getXMLEncoded()'s purpose in url names?
On Fri, Mar 5, 2010 at 10:40, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
On 03/05/2010 10:06 AM, Thomas Mortagne wrote:
You forget part of what i said: "(in xwiki/2.0 syntax)". There is not
such thing as "interpreted but not rendered" with xwiki/2.0 syntax.
On Fri, Mar 5, 2010 at 04:58, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
I know that this is what it does, but why? The semantics of this method
changed over time. The method used (with 1.0 syntax) to return whatever
was in the title, interpreted but not rendered. So, if it did contain
html markup in it, then that was it. But the wiki markup wasn't rendered
into HTML. And it still behaves this way for the value placed in the
title field. On 03/02/2010 08:20 PM, Thomas Mortagne wrote:
public String getDisplayTitle(XWikiContext context)
{
return getRenderedTitle(Syntax.XHTML_1_0, context);
} On Tue, Mar 2, 2010 at 18:25, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
> On 03/02/2010 05:01 PM, Joel Forsberg wrote:
>>
>> Greetings
>>
>> On my wiki using swedish characters for xwiki page titles give ugly but
>> working entries in all panels, e.g. "Backlinks" "Recent
modifications" and "My
>> recent modifications"
>>
>> An example is having:
>> "Startsidor för våra intresseområden"
>> ...instead of the correct:
>> "Startsidor för våra intresseområden"
>>
>> Another example is putting thiss wiki code on top of a page:
>> = header that<look ugly> here =
>>
>> The script responsible for for the texts in the panels is as follow:
>>
>> <span class="panelitem">
>> <a href="$rdoc.getURL('view')">
>> $xwiki.getXMLEncoded($rdoc.displayTitle)
>> </a></span>
>>
>> I've noticed that changing the third line into only $rdoc.displayTitle will
>> produce a nice looking entry, and $rdoc is set via
>>
>> #set($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
>>
>> Now, can anyone see a purpose of using getXMLEncoded() for this? As far as I
>> have seen, it only breaks things.
>
> This is not caused by getXMLEncoded, it merely makes the problem
> visible. This method must be used in order to prevent other problems:
> Invalid XML, broken layout, XSS...
>
> The problem is that the code inside getDisplayTitle wrongly uses a XML
> escaping option.
No, this is valid because the job of $rdoc.displayTitle is to produce
xhtml content and theses are valid XML escapes.
Where does it say that it should produce xhtml content?
So, I don't agree with the behavior change and the inconsistency it creates.
--
Thomas Mortagne
>
> Assuming that it should produce xhtml, the behavior is inconsistent. If
> the title is placed in the document.title field, then it returns
> characters; if it is placed in the first heading, it returns escapes. If
> we use wiki syntax in the document.title, we get back wiki syntax; if we
> use wiki syntax in the first heading, we get back HTML. That is totally
> inconsistent and confusing.
>
> This is an API design problem that should be discussed further on the
> dev list.
>
>
>
> Going back to this specific problem, I think that it should be solved by
> using the plaintext output syntax, since inside a panel we're not
> interested in formatting or other markup inside the title, just the
> textual content.
>
>> So you don't need to
>> use getXMLEncoded because any xml content is already properly escaped
>> (in xwiki/2.0 syntax).
>
> I need to use getXMLEncoded because the title doesn't always come from
> the content.
>
>> When you want a plain text version of the title you should use
>> $rdoc.getRenderedTitle("plain/1.0").
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
2:10 p.m.
New subject: [xwiki-users] What is $xwiki.getXMLEncoded()'s purpose in url names?
On Friday 05 March 2010 04:58:57 Sergiu Dumitriu wrote:
I need to use getXMLEncoded because the title
doesn't always come from
the content.
I saw the suggestion to modify the getXMLEncoded route on the JIRA ticket, so
I decided to do some testing with that. I only know two ways to set the title
for a document (are there more?) either from the content or the title, and
here's the results from those. (I have edited the out some hrefs="")
Case 1: Having a document where title field is blank, but having a section as
Document 1: = A damn <hr /> ruler =
Document 2: = Att-göra-lista =
Results:
$rdoc.displayTitle
1 <a>A damn <hr /> ruler</a>
2 <a>Att göra-lista</a>
$xwiki.getXMLEncoded($rdoc.getRenderedTitle('plain/1.0')
1 <a>A damn <hr /> ruler</a>
2 <a>Att göra-lista</a>
Visually: all the results appears okay and the same in Firefox. (I wonder if
IE versions can handle the XML output?) The xml route outputs UTF-8
characters, whereas displayTitle escapes them correctly even if the browser
selects wrong character encoding. However, the rest of the wiki use utf-8
consistently so that later case is not likely an issue.
Case 2: Putting the same in proper title field.
Results:
$rdoc.displayTitle
1 <a>= A damn </a><hr/><a> ruler =</a>
2 <a>= Att göra-lista =</a>
$xwiki.getXMLEncoded($rdoc.getRenderedTitle('plain/1.0')
1 <a>= A
damn</a><p><a></a></p><hr/><a></a><p><a>ruler
=</a></p>
2 <a>= Att göra-lista =</a>
Visually: As you see, the characters are not escaped at all when using the
title, no matter what method is being used. Guessing would make me say the
title field is buggy. The xml route even puts in a few extra <p> tags for some
reason.
I think the proper title field needs to be fixed in some way to escape special
characters before this can be fixed. It might also be good to have an example
where getXMLEncoded() does any good for panel links at the moment, for testing
purposes?
-Regards, Joel
3:06 p.m.
On 03/05/2010 02:10 PM, Joel Forsberg wrote:
On Friday 05 March 2010 04:58:57 Sergiu Dumitriu
wrote:
No, these are the only ones. Actually, as a fallback, if there is not
title in any of these places, then the document name is used.
I need to use getXMLEncoded because the title
doesn't always come from
the content.
I saw the suggestion to modify the getXMLEncoded route on the JIRA ticket, so
I decided to do some testing with that. I only know two ways to set the title
for a document (are there more?) either from the content or the title, and here's the results from those. (I have edited the
out some hrefs="")
Case 1: Having a document where title field is blank, but having a section as
Document 1: = A damn<hr /> ruler =
Document 2: = Att-göra-lista =
Results:
$rdoc.displayTitle
1<a>A damn<hr /> ruler</a>
2<a>Att göra-lista</a>
$xwiki.getXMLEncoded($rdoc.getRenderedTitle('plain/1.0')
1<a>A damn<hr /> ruler</a>
2<a>Att göra-lista</a>
Visually: all the results appears okay and the same in Firefox. (I wonder if
IE versions can handle the XML output?) The xml route outputs UTF-8
characters, whereas displayTitle escapes them correctly even if the browser
selects wrong character encoding. However, the rest of the wiki use utf-8
consistently so that later case is not likely an issue.
Case 2: Putting the same in proper title field.
Results:
$rdoc.displayTitle
1<a>= A damn</a><hr/><a> ruler =</a>
2<a>= Att göra-lista =</a>
$xwiki.getXMLEncoded($rdoc.getRenderedTitle('plain/1.0')
1<a>= A
damn</a><p><a></a></p><hr/><a></a><p><a>ruler
=</a></p>
This is caused not by the display code, but by the fact that the result
is used inside a panel written with the 1.0 syntax, which doesn't know
that the result is already processed. You can check that by actually
using this in the panel:
{pre}<span class="panelitem"><a
href="$rdoc.getURL('view')">$xwiki.getXMLEncoded($rdoc.getRenderedTitle('plain/1.0'))</a></span>{/pre}
{pre}{/pre} prevents re-rendering the content.
The result with this is:
A damn
----
ruler
Which again is a bit wrong, but this is a bug in the core, it always
assumes that the content that it got from the title field is
velocity+HTML, even if the page is in xwiki/2.0 syntax.
2<a>= Att göra-lista =</a>
Visually: As you see, the characters are not escaped at all when using the
title, no matter what method is being used. Guessing would make me say the
title field is buggy. The xml route even puts in a few extra<p> tags for some
reason.
I think the proper title field needs to be fixed in some way to escape special
characters before this can be fixed. It might also be good to have an example
where getXMLEncoded() does any good for panel links at the moment, for testing
purposes?
Try to put one of these in the title field:
When to use </div>
=> badly broken display
CrossSiteScripting example: <script>alert('I pwnd U')</script>
=> bad, bad, bad
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4:30 p.m.
New subject: [xwiki-users] Searching workaround for HTML in title-field
On Friday 05 March 2010 15:06:34 Sergiu Dumitriu wrote:
<snipped>
{pre}{/pre} prevents re-rendering the content.
The result with this is:
A damn
----
ruler
Which again is a bit wrong, but this is a bug in the core, it always
assumes that the content that it got from the title field is
velocity+HTML, even if the page is in xwiki/2.0 syntax.
Do you happen to know the JIRA ticket for this bug? (if there is one?)
The {pre} seems to dodge some of the unwanted effects, but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to have
disappeared, instead leaving a <p>-tag artifact depending on circumstances.
CrossSiteScripting example: <script>alert('I
pwnd U')</script>
=> bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
Kind regards, Joel
6:55 p.m.
New subject: [xwiki-users] Searching workaround for HTML in title-field
On 03/05/2010 04:30 PM, Joel Forsberg wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Friday 05 March 2010 15:06:34 Sergiu Dumitriu
wrote:
<snipped>
There isn't one AFAIK.
{pre}{/pre} prevents re-rendering the content.
The result with this is:
A damn
----
ruler
Which again is a bit wrong, but this is a bug in the core, it always
assumes that the content that it got from the title field is
velocity+HTML, even if the page is in xwiki/2.0 syntax.
Do you happen to know the JIRA ticket for this bug? (if there is one?) The {pre} seems to dodge some of the unwanted effects,
but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to have
disappeared, instead leaving a<p>-tag artifact depending on circumstances.
Yes, that's another bug in the 1.0 renderer, one which can't be easily
avoided: the panel display itself is in a 1.0 document, which sees the
{pre} and "uses" it. As a workaround, you can edit the panel using the
object editor.
CrossSiteScripting example:<script>alert('I pwnd U')</script>
=> bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
Kind regards, Joel 
12 Jun
12 Jun
5:30 p.m.
New subject: [xwiki-users] Searching workaround for HTML in title-field
Joel Forsberg wrote:
Do you happen to know the JIRA ticket for this bug? (if there is one?)
http://jira.xwiki.org/jira/browse/XE-24 but it is for previous search
engine.
The {pre} seems to dodge some of the unwanted effects,
but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to have
disappeared, instead leaving a <p>-tag artifact depending on circumstances.
--
If you want to get to the top, you have to start at the bottom
CrossSiteScripting example:
<script>alert('I pwnd U')</script>
=> bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
6:05 p.m.
New subject: [xwiki-users] Searching workaround for HTML in title-field
This is not a problem only with the search field. It's a security policy that
XWiki allows it's users to run script. In syntax 1.0 you are allowed to type
HTML (and thus script) into the document, in syntax 2.0 you can use HTML in
the document by invoking the HTML macro.
My opinion is that to prevent users from running script you would have to set up
an output filter such as Apache mod_filter and implement a policy which blocks all
script which is in parts of the page which are user editable.
Caleb
Ivan Levashew wrote:
Joel Forsberg wrote:
Do you happen to know the JIRA ticket for this
bug? (if there is one?)
http://jira.xwiki.org/jira/browse/XE-24 but it is for previous search
engine.
The {pre} seems to dodge some of the unwanted
effects, but in turn makes
further editing the script difficult. Next time I edit the {pre} seems to have
disappeared, instead leaving a <p>-tag artifact depending on circumstances.
CrossSiteScripting example:
<script>alert('I pwnd U')</script>
=> bad, bad, bad
That is exatly what I would like to avoid, hehe. :)
6:29 p.m.
New subject: [xwiki-users] Searching workaround for HTML in title-field
James DeLisle wrote:
This is not a problem only with the search field.
It's a security policy that
XWiki allows it's users to run script. In syntax 1.0 you are allowed to type
HTML (and thus script) into the document, in syntax 2.0 you can use HTML in
the document by invoking the HTML macro.
My opinion is that to prevent users from running script you would have to set up
an output filter such as Apache mod_filter and implement a policy which blocks all
script which is in parts of the page which are user editable.
I have a short experience with Jaxer. It is not maintained, but is
pretty usable if starting from scratch is OK for you. Notable difference
is that most operations are performed on structured DOM trees as opposed
to structureless strings in e. g. PHP. The engine is serverside Mozilla,
so the tricks like innerHTML are working, but strings are exception
instead of a rule in the world of Jaxer.
I think, sooner or later it would be evident that next major revision of
X-Wiki must use structured data instead of all that
easy-to-forget-because-anyway-it-mostly-works escaping.
This makes sense because, for instance, one might want to enable users
to post into common blog but prevent them from storing scripts. There is
no "string noscript(string)" function. It is far beyond mere escaping.
Even if such function existed, parsing and serializing is CPU-costly.
--
If you want to get to the top, you have to start at the bottom
7:17 p.m.
New subject: [xwiki-users] Searching workaround for HTML in title-field
Ivan Levashew wrote:
James DeLisle wrote:
We have something like that. We call it XDOM. It can be rendered into XHTML, PDF
OpenOffice export etc.
http://code.xwiki.org/xwiki/bin/view/Modules/RenderingModule
There is an issue for adding means to manipulate the XDOM using server side script.
http://jira.xwiki.org/jira/browse/XWIKI-5234
2 problems:
1. Lots of content (including all of the .vm templates) is in Syntax 1.0 which doesn't
use the new rendering module.
2. Syntax 2.0 parsers contain lots of code and have bugs of their own.
IMO security code should be as small and as heavily reviewed as possible.
This is not a problem only with the search field.
It's a security policy that
XWiki allows it's users to run script. In syntax 1.0 you are allowed to type
HTML (and thus script) into the document, in syntax 2.0 you can use HTML in
the document by invoking the HTML macro.
My opinion is that to prevent users from running script you would have to set up
an output filter such as Apache mod_filter and implement a policy which blocks all
script which is in parts of the page which are user editable.
I have a short experience with Jaxer. It is not maintained, but is
pretty usable if starting from scratch is OK for you. Notable difference
is that most operations are performed on structured DOM trees as opposed
to structureless strings in e. g. PHP. The engine is serverside Mozilla,
so the tricks like innerHTML are working, but strings are exception
instead of a rule in the world of Jaxer.
I think, sooner or later it would be evident that next major revision of
X-Wiki must use structured data instead of all that
easy-to-forget-because-anyway-it-mostly-works escaping.
This makes sense because, for instance, one might want to enable users
to post into common blog but prevent them from storing scripts. There is
no "string noscript(string)" function. It is far beyond mere escaping.
Even if such function existed, parsing and serializing is CPU-costly.
I think you could strip all types of script invocation from a stream of xml
without actually parsing the xml.
If you can't do it with sed, it's not worth doing ;)
5263
days inactive
5365
days old
15 comments
5 participants
participants (5)
-
Caleb James DeLisle -
Ivan Levashew -
Joel Forsberg -
Sergiu Dumitriu -
Thomas Mortagne