Java lti library failing to validate request when special characters are present

Jump to solution
pgo586
Community Contributor

I'm having a situation in which a Canvas user has set special characters in his name (a Spanish accent, a tilde on top of an 'n') and this is causing the Java LTI library I use for validating the request to fail the LTI validation. The specific library I use is 'blti-sandwich' (written by Blackboard folks a long time ago but applicable in general and open source), which has worked very well for me until now. I suspect that perhaps Canvas is not encoding the request parameter strings using UTF-8, and this might be causing trouble.

I wonder if anybody else out there coding in Java ever encountered a similar problem, and if so, how did they resolve it. Thanks in advance.

1 Solution
pgo586
Community Contributor

I finally arrived to a solution for the problem, which I suspect should be useful for most (if not all) Java developers writing LTI apps for Canvas. First of all, this is definitely an encoding issue that affects all Java such apps using an LTI library which in turn depends on OAuth libraries, which in turn directly grab http parameters out of the http request. I tried both 'blti-sandwich' and' basiclti-util'  as my LTI libraries , but any other existing LTI library which depends on the same or similar OAuth libraries will run into the same issue.

The problem is that the LTI launch request from Canvas is interpreted by the servlet container as having NO character encoding. This therefore makes the container assume the default in your time zone (normally something like ISO-5589...). Therefore as parameters are not correctly decoded, the LTI signatures computed by your servlet (using the LTI libraries) and Canvas then do not coincide, no matter which library I mention above you actually use (as the libraries directly grab parameters from the request, which have been incorrectly decoded).

The solution I came up with was to add a servlet filter to my LTI servlet that ensures the request's character encoding is set to UTF-8 before anybody else can grab any of the parameters in the request.

More specifically, the filter includes the following simple definition:

@Override

  public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain)

  throws IOException, ServletException {

  request.setCharacterEncoding("UTF-8");

  filterChain.doFilter(request, response);

  }

Hope this helps others avoid the same problem. Thanks!

View solution in original post