[WG: Sakai QA] [Building Sakai] 2.6.2: SAK-17171 (Botimer vs Botimer)
John F. Hall
hall at UDel.Edu
Mon Jan 4 08:24:33 PST 2010
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
More information about the sakai-qa
mailing list