1edtech / basiclti-util-java Goto Github PK

The replaceResultRequest XML template is currently not valid. According to the implementation guide there should be an imsx_messageIdentifier key.

I have encountered this problem when implementing an LTI tool for edX. The LTI implementation of edX seems to check this key. It throws the following error if the identifier is missing:

Failed to parse imsx_messageIdentifier from XML request body

Hi Everyone,

Sending Outcomes is signed using HMAC-SHA1. IMS is deprecating support for SHA1 starting Jan 2020. Is there a way to update the library to support SHA-256?

redacted

The README.md file in master currently mentions the dependency you should use as:

<dependency>
    <groupId>org.imsglobal</groupId>
    <artifactId>basiclti-util</artifactId>
    <version>1.0.0</version>
</dependency>

However, in the pom.xml file in master defines the artifact as:

<groupId>org.imsglobal</groupId>
<artifactId>basiclti-util</artifactId>
<version>1.1.1</version>

There is a discrepancy between the '1.1.1' and the '1.0.0'. I believe it is the README.md file that should be changed.

The LtiOauthVerifier always creates a new SimpleOAuthValidator for each and every call of the verify method. So usedNonces is always empty and the check will never fail. Also if LtiOauthVerifier itself is a singleton.
I think this is a bug. Or did I miss something here?

Sakai is rejecting replaceResult calls with "Did not find oauth_body_hash". Moodle requires it as well ( https://github.com/moodle/moodle/blob/master/mod/lti/OAuthBody.php ).

I have a WIP commit up at bluej100@9d6d965#diff-d41d8cd98f00b204e9800998ecf8427e , but it breaks signing.

Just tried using this via mvn, got this error:

[INFO] ------------------------------------------------------------------------
Downloading: https://repo.maven.apache.org/maven2/org/imsglobal/basiclti-util/1.1.2/basiclti-util-1.1.2.pom
[WARNING] The POM for org.imsglobal:basiclti-util:jar:1.1.2 is missing, no dependency information available
Downloading: https://repo.maven.apache.org/maven2/org/imsglobal/basiclti-util/1.1.2/basiclti-util-1.1.2.jar
[INFO] ------------------------------------------------------------------------

The POM is very vanilla:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.meetingone.hello</groupId>
  <artifactId>hello</artifactId>
  <version>0.0.1</version>
  <packaging>jar</packaging>

  <name>hello</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.imsglobal</groupId>
      <artifactId>basiclti-util</artifactId>
      <version>1.1.2</version>
    </dependency>

  </dependencies>
</project>

I'm not a maven guru, so feel free to tell me if I've got a dumb mistake here.

LTI 1.1 POX replaceResultRequest header has following XSD

<xs:complexType name="imsx_RequestHeaderInfo.Type" mixed="false">
    <xs:annotation>
        <xs:documentation source="umldocumentation">...</xs:documentation>
    </xs:annotation>
    <xs:sequence>
        <xs:element ref="imsx_version" minOccurs="1" maxOccurs="1"/>
        <xs:element ref="imsx_messageIdentifier" minOccurs="1" maxOccurs="1"/>
        <xs:element ref="imsx_sendingAgentIdentifier" minOccurs="0" maxOccurs="1"/>
    </xs:sequence>
</xs:complexType>

so there must be 1 message identidier imsx_messageIdentifier but replaceResultRequest has not it. see full schema definition here
https://www.imsglobal.org/lti/media/ltiv1p1/OMSv1p0_LTIv1p1Profile_SyncXSD_v1p0.xsd

as result some LMS with schema verification can't accept replaceResultRequest POX message generated by this library. E.g. Blackboard 9.1.201404.160205 return HTTP 500 status with stack trace on the server site as following:

2017-01-13 11:21:27 -0500 - Failure/Unsupported error sent to LTI Grade Callback request: - blackboard.blti.outcomes.NoPOXDataException: //lti:imsx_messageIdentifier
at blackboard.blti.outcomes.POXDocument.throwIfEmpty(Unknown Source)
at blackboard.blti.outcomes.POXDocument.getXPathValue(Unknown Source)
at blackboard.blti.outcomes.POXDocument.getTagValue(Unknown Source)
at blackboard.blti.outcomes.consumer.POXRequest.getMessageIdentifier(Unknown Source)
at blackboard.blti.outcomes.consumer.POXOutcomesRequestHandler.setMessageIdentifiers(Unknown Source)
at blackboard.blti.outcomes.consumer.POXOutcomesRequestHandler.handleSuccess(Unknown Source)
at blackboard.blti.outcomes.consumer.POXOutcomesRequestHandler.handleReplaceResult(Unknown Source)
at blackboard.blti.outcomes.consumer.POXOutcomesRequestHandler.handle(Unknown Source)
at blackboard.webapps.gradebook2.lti.LTI11GradingEndPointServlet.doPost(LTI11GradingEndPointServlet.java:26)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

In the usage for a provider, for verifying a user, the readme states that you should use

LtiVerificationResult ltiResult = ltiVerifier.verify(request, request.getParameter("oauth_consumer_key"));

when in reality you want to use

LtiVerificationResult ltiResult = ltiVerifier.verify(request, secret_key);

where secret_key is the stored secret key for the consumer who is making the request. This is confusing and should be updated.

A request from Canvas will have keys with multiple values such as

    ext_outcome_data_values_accepted=[url,text]

If you aren't implementing a servlet (e.g. in a Play framework application), you cannot use LTIVerifier.verifyParameters. There is no Map<String, String> that you can pass.

You need to be able to pass a Map<String, String[]> or a similar multi-valued map.

Also, are you including key/value pairs in the url in the verification? If so, it would be good to clearly state that in the docs. If not, that would be a useful service to provide.

When signing a request, LtiOauthSigner does not add oauth_body_hash to the Authorization header.

Some Lti Consumers require the oauth_body_hash in order to validate an Lti request.

LtiOauthSigner should have an option to include oauth_body_hash, and it should be on by default.

Side note:
I have no idea what purpose it serves. Further, since GET requests have an empty body, the oauth_body_hash will always have the same hash: 2jmj7l5rSw0yVb%2FvlWAYkK%2FYBwk%3D

At runtime, servlet-api is supposed to be provided by the servlet container and not bundled in any war, ear, etc. The default maven dependency scope is compile, which will automatically and transitively pulled servlet-api into war files unless scope is set to provided.

<dependency>
     <groupId>javax.servlet</groupId>
     <artifactId>servlet-api</artifactId>
     <version>2.5</version>
     <scope>provided</scope>
</dependency>

While It can be worked around by specifically excluding in downstream pom files, it is poor behavior for a library to declare it with scope other than provided.

To reproduce:

create a spring controller with a method that contains a @RequestParam(required = false) parameter.
Eg.

	@Lti
	@RequestMapping(method = RequestMethod.POST)
	public String post(
			final LtiVerificationResult ltiResult,
			final HttpServletRequest request,
			final ModelMap modelMap,
			@RequestParam(required = false) final Integer someId) throws IOException, OAuthException, GeneralSecurityException {

Results in:

java.lang.NullPointerException
	at org.imsglobal.aspect.LtiLaunchVerifier.verifyLtiLaunch(LtiLaunchVerifier.java:53)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
	at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
	at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:68)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:168)
	at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:653)
	at com.intrallect.dalo.spring.controller.LtiController$$EnhancerBySpringCGLIB$$866b786.post(<generated>)

Is this project still functional?

I have a spring preauth filter that is trying to use BasicLTIUtil.validateMessage(req,url,secret) to verify signatures from a LaunchPad LMS, and it only works occasionally. Same when i test it with other LTI-1p0 Tool Consumer emulators. Sometimes it succeeds, but more often i get invalid signature errors.

There's not much documentation, and i can't find any reason why this is wrong. I'm wondering if this is due to outdated dependencies in this project? Especially wondering about this one:

        <groupId>net.oauth.core</groupId>
        <artifactId>oauth-provider</artifactId>
        <version>20100527</version>

Help?

Should the tool_consumer_profile in the ToolProxy.java be serialized to the ToolConsumer Object ?
Same thing for the resource_handler in the ToolProfile.

I added caliper library in android application,i configured url in defaults class,i want to send custom events to server,please provide event structure

Hi All,

I found one issue while using BasicLTIConstants.CONTEXT_TYPE_GROUP constant variable.
Issue is, as per the LTI specification (https://www.imsglobal.org/specs/ltiv1p1/implementation-guide) ContextType should have following
CourseTemplate,
CourseOffering,
CourseSection,
Group

All constants values are mentioned proper in BasicLTIConstants.java class but for CONTEXT_TYPE_GROUP it as follows

public static final String CONTEXT_TYPE_GROUP = "GROUP";

So basically it should be "Group"

https://github.com/IMSGlobal/basiclti-util-java/blob/master/src/main/java/org/imsglobal/lti/BasicLTIConstants.java

Thanks,
Anurag

I've just come across an LTI validation issue for a Canvas LTI app (using basiclti-util-java to do the LTI validation within Java) and a particular student whose name/lastname include special characters. The symptom is that the LTI validation fails for this student, while it succeeds when the special characters are removed from the user's name within Canvas. The special characters in question are Spanish characters (an accent +a tilde above an 'n').
While this tells me that character encoding must be an issue here, I cannot tell who is at fault (is it the Canvas LTI consumer sending incorrectly encoded strings, or is the basiclti-util-java library somehow at fault?).
Here's a bit more information that might help:
1- I've experimented with an alternative Java LTI library (blti-sandwich) and got the same result - failed validation-. I see that both libraries use the same underlying OAuth libraries, which might explain the uniformity here perhaps.
2- I've added a couple of logging messages within Java to print out the relevant http (lti-related) parameters being passed. When the name/lastname get printed out, they get shown with messed up characters - just what one would expect if reading with one encoding something that was encoded with a different one-. If I then re-encode these strings as UTF-8 strings within Java (reading them as ISO-8859_1 first) they then print out fine to the console. This seems to suggest that perhaps the strings sent over by the Canvas LMS were encoded using ISO 8859_1.
3- An alternative LTI app that uses PHP-based LTI validation (Blti library) written by a colleague validates correctly this particular user's request. This suggests that somehow the PHP-based LTI library is somehow avoiding the (special character) problem altogether.

Any thoughts will be appreciated. Thanks in advance.

See http://central.stage.sonatype.org/pages/apache-maven.html .
I'm happy to do this myself.

Because BasicLTIConstants does not know about content item specific parameters like data or content_items and so they get turned into custom parameters by BasicLTIUtil.cleanupProperties().

is the best way to fix this just to add all the parameters from the content item spec into BasicLTIContents or will that cause problems elsewhere? I can do a PR if this is acceptable or you can suggest another way of fixing.