Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-41782

tsugi-util rejecting valid application/xml content type

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Verified
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 11.4, 12.6, 19.1, 20.0 [Tentative]
    • Fix Version/s: 12.7, 19.3, 20.0 [Tentative]
    • Component/s: BasicLTI
    • Labels:
      None
    • 19 status:
      Verified
    • 12 status:
      Verified
    • 11 status:
      Please Merge
    • Test Plan:
      Hide

      The test plan for this is to follow the normal LTI 1.1 regression plan, add an LTI 1.1 tool and send a grade back.  If the grade is sent back then this did not introduce a regression.  It is tough to set up a tool that does not use the single mime type.

      Show
      The test plan for this is to follow the normal LTI 1.1 regression plan, add an LTI 1.1 tool and send a grade back.  If the grade is sent back then this did not introduce a regression.  It is tough to set up a tool that does not use the single mime type.

      Description

      This is a bug in the tsugi-util code that lives in Sakai that is also released separately under the Tsugi banner.  The bug came from Robert Bruening. 

      Here is the text from the tsugi-dev list:

      Found this issue in the basic-lti-util library developed by IMS, and it looks like tsugi-util has it as well.  The LTI spec specifies that the content type of all messages should be of type application/xml.  IMSPOXRequest as implemented checks that the content type is exactly application/xml, and rejecting any content type with optional parameters (ie charset).  Requests with optional parameters should be accepted, as long as the base content type is application/xml. We have LTI providers that have started sending contentType application/xml;charset=utf-8, so, I've created a pull request to tsugi-util to change IMSPOXRequest so it will accept content type of application/xml with optional parameters.  https://github.com/tsugiproject/tsugi-util/pull/4

      This change also caught the fact the org.apache.commons.lang.stringUtils is now org.apache.commons.text.StringUtils:

      https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringEscapeUtils.html

      https://stackoverflow.com/questions/47817480/why-was-org-apache-common-lang3-stringescapeutils-deprecated

      Thanks Apache.

       

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                csev Charles Severance
                Reporter:
                csev Charles Severance
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Git Source Code