[WG: Sakai QA] Webdav protocol inconsistencies between QA servers.
Berg, A.M.
A.M.Berg at uva.nl
Tue Jan 5 01:07:11 PST 2010
Hi all,
More for background information: I have checked various Sakai Qa servers including nightly for webdav protocol compatibility via the litmus tool and then parsed the results into an HTML table (http://builds.sakaiproject.org/litmus/2010/1/). There is some variation between servers due to what I assume is Sakai version, Mod_jk and SSL connections and other unknown factors. Therefore, if you are debugging webdav/browser issues it is well worth checking across a range of relevant servers.
I will write a Jira that is unassigned and if anyone works towards improving protocol consistency can then use it to act as an umbrella.
Alan
Alan Berg
Interim QA Director - The Sakai Foundation
Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam
http://home.uva.nl/a.m.berg
-----Original Message-----
From: sakai-dev-bounces at collab.sakaiproject.org on behalf of Charles Hedrick
Sent: Mon 1/4/2010 22:43
To: John F. Hall
Cc: Sakai QA; Sakai Mailing List Dev
Subject: Re: [Building Sakai] 2.6.2: SAK-17171 (Botimer vs Botimer)
Please see SAK-16989 for what we did in Samigo. Is this the case you're concerned about? In my view this isn't formatted text, so processFormattedText doesn't belong there. When grading, < is quoted, and there isn't a rich text editor when entering, so there's no reason to mess with < at all.
On Jan 4, 2010, at 11:24 AM, John F. Hall wrote:
> For the meantime, what is the recommendation for schools running 2.6?
>
> Students are losing test data when they hit this issue in Samigo, so we
> need to patch soon.
>
> Just applying the patch in KNL-66 seems to fix it, but will that be
> future compatible? Should we wait until this is ironed out more?
>
> -John
>
> Feliz Gouveia wrote:
>>
>> and for the output escaping, depending on the output channel, we could
>> use Apache StringEscapeUtils. Escaping the input is probably not a
>> good idea, besides escaping for sql (which is done by the database
>> driver).
>>
>> Feliz
>>
>> 2009/12/24 <nate.angell at rsmart.com <mailto:nate.angell at rsmart.com>>
>>
>> Folks may find it instructive to look at the Drupal model, which I
>> understand does some validation on input to prevent CSS exploits/etc,
>> but tries to store input as is and filter on output, which allows all
>> sorts of magical transformations.
>>
>> Maybe too much of a paradigm shift for Sakai 2, but for Sakai 3?
>>
>> On Dec 22, 2009, at 12:10 PM, "Stephen Marquard"
>> <stephen.marquard at uct.ac.za <mailto:stephen.marquard at uct.ac.za>
>>> wrote:
>>
>>> We should ideally have "one right way" to handle content validation
>>> and escaping in Sakai, from input through to storage and output.
>>>
>>> In general I would say this should be:
>>>
>>> Plain text: accept any input, store as is, escape to html markup on
>>> output using escapeHtml (e.g. > to >)
>>> Formatted text: validate using processFormatted text on input, store
>>> as validated ("safe") html, output as-is.
>>>
>>> T&Q is the most complex case, because it has input fields that can
>>> be entered either as plain text or formatted. This is really a
>>> special case of storing formatted, text, viz.
>>>
>>> Input as plain text, escape to html markup for storage, output as-is
>>> Input as formatted text, validate using processFormattedText, store
>>> as validated ("safe") html, output as-is
>>>
>>> Unfortunately different tools handle it in different ways, with some
>>> escaping on input and others escaping on output. This is safe so
>>> long as the model is consistently applied but as noted, potentially
>>> unsafe is the assumption about whether stored content is validated
>>> or not and/or escaped or not is changed.
>>>
>>> If fixes do change the assumptions about stored content, then they
>>> should come with a conversion step (for example if it was previously
>>> assumed that content would be escaped on output and that's no longer
>>> the case because content is assumed stored as "safe" html, then the
>>> conversion should pass all stored content through
>>> processFormattedText to validate it).
>>>
>>> Regards
>>> Stephen
>>>
>>>>>> Anthony Whyte <arwhyte at umich.edu <mailto:arwhyte at umich.edu>>
>> 12/22/2009 9:08 PM >>>
>>> Concerns have been raised relative to the proposed solution for
>>> SAK-17171 first noted in Samigo and later in chat and msgcntr
>> wherein
>>> text input including unbalanced tag-like characters (e.g., less
>> than/
>>> greater than characters (e.g., "<", ">")) result in string index out
>>> of range exceptions when processed/validated by
>>> FormattedText.processFormattedText(). It has been suggested
>> that the
>>> problem originates in a failure at the tool level to distinguish
>>> properly between input intended as plain text (e.g., a > b) and rich
>>> text (e.g., HTML).
>>>
>>> Stephen Marquard argues in KNL-66 that plain text input should be
>>> escaped via Validator.escapeHTML while rich text should be processed
>>> and validated by FormattedText.processFormattedText(). This is the
>>> approach adopted in the SAK-17171 patch provided by Noah
>> Botimer. If
>>> I'm reading the Jira comments correctly, Noah has since backed away
>>> from his patch, describing it in SAK-17171 as the "wrong approach."
>>> Aaron Zeckoski agrees, arguing that the approach represents "a
>>> fundamental change in the way data is stored. It is definitely no
>>> longer a simple bug fix if you change the stored data or the way the
>>> data is stored and is probably inappropriate for a merge into a .x
>>> branch. I would encourage finding a solution which does not
>> change the
>>> way data is stored if that is possible."
>>>
>>> Escaping plain text data intended for storage appears problematic to
>>> me (while escaping it when outputting it to the browser does not).
>>> Given the debate here (if I've summarized it correctly) I'm holding
>>> off merging the 2.6.x patch for SAK-17171 until we sort this out.
>>>
>>> One fix we should consider implementing is providing
>>> FormattedText.processFormattedText() with a friendly error
>> message if
>>> text with unbalanced tags are encountered.
>>>
>>> Anth
>>>
>>>
>>>
>>> kernel-1.0.12 JavaDoc
>>>
>> http://source.sakaiproject.org/release/kernel/1.0.12/sakai-kernel-util/apidocs/org/sakaiproject/util/FormattedText.html#processFormattedText(java.lang.String,%20java.lang.StringBuilder,%20boolean,%20boolean)
>> <http://source.sakaiproject.org/release/kernel/1.0.12/sakai-kernel-util/apidocs/org/sakaiproject/util/FormattedText.html#processFormattedText%28java.lang.String,%20java.lang.StringBuilder,%20boolean,%20boolean%29>
>>>
>> http://source.sakaiproject.org/release/kernel/1.0.12/sakai-kernel-util/apidocs/org/sakaiproject/util/FormattedText.html#escapeHtml(java.lang.String,%20boolean)
>> <http://source.sakaiproject.org/release/kernel/1.0.12/sakai-kernel-util/apidocs/org/sakaiproject/util/FormattedText.html#escapeHtml%28java.lang.String,%20boolean%29>
>>>
>> http://source.sakaiproject.org/release/kernel/1.0.12/sakai-kernel-util/apidocs/org/sakaiproject/util/Validator.html#escapeHtml(java.lang.String)
>> <http://source.sakaiproject.org/release/kernel/1.0.12/sakai-kernel-util/apidocs/org/sakaiproject/util/Validator.html#escapeHtml%28java.lang.String%29>
>>>
>>> More info:
>>> kernel: http://jira.sakaiproject.org/browse/KNL-66
>>> msgcntr: http://jira.sakaiproject.org/browse/SAK-17171
>>> samigo: http://jira.sakaiproject.org/browse/SAK-14153
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>> <mailto:sakai-dev at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org
>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>
>>> with a subject of "unsubscribe"
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>> <mailto:sakai-dev at collab.sakaiproject.org>
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org
>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org>
>>> with a subject of "unsubscribe"
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> <mailto:sakai-dev at collab.sakaiproject.org>
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org
>> <mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a
>> subject of "unsubscribe"
>>
>>
>>
>>
>> --
>> Feliz Ribeiro Gouveia
>>
>> Universidade Fernando Pessoa http://www.ufp.pt
>> Centro de Recursos Multimediaticos Tel 351-22.507.13.06
>> M.I.N.D. Lab Fax 351-22.550.82.69
>> Pr 9 de Abril 349 fribeiro at ufp.edu.pt
>> <mailto:fribeiro at ufp.edu.pt>
>> P-4249-004 Porto
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
> --
> ____________ John F. Hall ____________
> Programmer/Analyst, IT-Web Development
> University of Delaware
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20100105/4bd28787/attachment-0001.html
More information about the sakai-qa
mailing list