Encountering issues configuring LTI with Moodle

[Cavin B.]

We're trying to configure LTI with Moodle on a server that has NGINX in front of Opencast acting as an HTTPS proxy. We followed this guide to configure the Opencast portion: https://docs.opencast.org/r/4.x/admin/modules/ltimodule/

Moodle is configured like this

NGINX is configured like this

# This section is needed to proxy web-socket connections
map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
}


# HTTP
server {
        listen 80; # If this is not a default server, remove "default_server"
        listen [::]:80 ipv6only=on;

        server_name <AdminURL>;

        # Redirect non-SSL to SSL
        location / {
                rewrite ^ https://<AdminURL>$request_uri? permanent;
        }
}

# HTTPS server
server {
        listen 443 ssl http2; # We enable HTTP/2 here (previously SPDY)
        server_name <AdminURL>; # This domain must match Common Name (CN) in the SSL certificate

        ssl_certificate /etc/ssl/<AdminURL>.crt;
        ssl_certificate_key /etc/ssl/<AdminURL>.key;

        # Increased values to allow for large file uploads
        client_body_timeout 14400s; # 240 minutes or 4 hours
        client_max_body_size 50G; # 50GB max

        location / {
                # Pass request to local Opencast listener
                proxy_pass http://127.0.0.1:8080;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade; # Allow websockets
                proxy_set_header Connection $connection_upgrade;
                proxy_set_header X-Forwarded-For $remote_addr; # Preserve client IP
                proxy_set_header X-Forwarded-Ssl on; # Forward SSL requests (required for LTI)
                #proxy_set_header X-Forwarded-Protocol https;
                #proxy_set_header X-Url-Scheme https;
                #proxy_redirect https://<AdminURL> http://<AdminURL>:8080;
        }
}

And this is the error we get:

[Cavin B.]

Forgot to mention, we are currently on Opencast 4.4

[Dietmar Zenker]

Hi Cavin,

I had the same problems when configuring our ILIAS LTI plugin for Opencast. Try to add "custom_" as prefix to your parameters, e.g.

custom_tool = ltitools/series/index.html
custom_series = YOUR_SERIES_ID

Cheers,

Dietmar

[Cavin B.]

Hi Dietmar,
Thank you for your suggestion, unfortunately it produced the same result as before

[Paul Pettit]

Hi Cavin,

Have you got your org.opencastproject.server.url set correctly to https://my.proxy.server ?

Also I have some more headers set than you, not sure if they are all required (in haproxy syntax...):

    http-request set-header X-Forwarded-Proto https if  { ssl_fc }

    http-request set-header X-Forwarded-Ssl on if  { ssl_fc }

    http-request set-header X-Forwarded-Port %[dst_port]

Thanks,

Paul.

--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.

[Cavin B.]

HI Paul,

We have 

org.opencastproject.server.url=https://<AdminURL>

so that should be alright right?

we added the following headers

proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header X-Forwarded-Protocol https;
proxy_set_header X-Forwarded-Port 443;

but end up with the same thing, but weirdly if I go to https://<AdminURL>/lti my browser forwards it to https://127.0.0.1:8443/admin-ng/login.html ... not sure if that's right?

[Paul Pettit]

Hi Cavin,

You definitely need the server.url of the node you are trying to use with LTI via HTTPS to be your proxy address, or the signature will not match and it will not let you log in via LTI.

There are lots of weird errors with forwarding in Opencast but not sure about the one you mention, that is definitely not right though.

Thanks,

Paul.

[Cavin B.]

Hey Paul,
 

So, server.url is set to https://myopencast.domain.tld which is the same address that one would use to get to the actual admin or Engage UI. NGINX responds to https://myopencast.domain.tld and proxies it to http://127.0.0.1:8080. Opencast itself is only listening on 127.0.0.1:8080. Is that correct or should I make any changes?

I'm baffled as to why Opencast is forwarding requests to https://127.0.0.1:8443/...

[opencast@opencast-worker1 opencast]$ curl -k -I http://myopencast.domain.tld/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.12.2
Date: Thu, 16 Aug 2018 15:50:03 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Location: https://myopencast.domain.tld/

[opencast@opencast-worker1 opencast]$ curl -k -I https://myopencast.domain.tld/
HTTP/1.1 302 Found
Server: nginx/1.12.2
Date: Thu, 16 Aug 2018 15:50:12 GMT
Connection: keep-alive
Set-Cookie: JSESSIONID=12uk78njo93pbofbcthvq7y2x;Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: https://127.0.0.1:8443/admin-ng/login.html;jsessionid=12uk78njo93pbofbcthvq7y2x

Actual URLS changed

[Paul Pettit]

Hi Cavin,

Yes I think that is right. As long as the server.url matches the tool you set up in moodle it should generate the signature correctly (assuming you have also set the CONSUMERKEY and CONSUMERSECRET the same on both opencast and moodle too.

I've no idea about the weird forwarding though - you must have 127.0.0.1:8443 somewhere in your config I suppose? or maybe one of those extra headers is actually breaking things?

Paul.

[Cavin B.]

Hey Paul,

I think i've made some progress....

I et a login prmopt when trying to launch the LTI link now, but i can't actually login. It just bumps me back to the login page whin I try.
I have the LTI series configured like so:

Am I missing anything? (Anonymous was added for troubleshooting but I'm planning on removing it...)
Thanks!
Cavin

[Paul Pettit]

Hi Cavin,

There are a bunch of things you can try to debug what is happening. 

You can open the browser's dev tools before clicking on the lti tool then look in the network tab to see what values are being posted to /lti

You can visit /info/me.json directly after clicking on the lti tool to see what rights you have been granted.

You can go to /lti in the browser to get some info on your session.

In fact if you remove the "tool" custom parameter opencast will give you links to both those pages.

I actually find testing using https://lti.tools/saltire/tc is easier at first as you can easily see what is going on without resorting to the dev tools and once you have that working you can then try and configure your VLE in the same way.

Hope that helps!

Paul.

[Cavin B.]

Hi Paul,

So as of this morning it looks like LTI is partially working. We can get to the "test" page, but when we click to continue we get a login prompt. Opencast logs lead me to believe that we're past the invalid signature issue: 2018-08-16 14:25:16,706 | DEBUG | (OAuthProviderProcessingFilter:155) - Signature validated.

The weird thing is even if I log in at the prompt I can't see the series and my user is an admin.

[Dietmar Zenker]

Hi Cavin,

are there any log messages similar to

2018-08-17 14:08:27,722 | INFO  | (LtiLaunchAuthenticationHandler:221) - Returning user with x authorities
that gives you a hint that authorization was successful?

What happens if you replace "/lti" by "ltitools/series/index.html?series=SERIES_ID" in your browser's address bar?

Does your Moodle activity of LTI object offer the option to generate some debug output, e.g. which parameters will be transferred to the LTI tool provider?

Greets,

Dietmar

[Cavin B.]

HI Dietmar,

Yes 2018-08-17 08:45:57,979 | INFO | (LtiLaunchAuthenticationHandler:221) - Returning user with 3 authorities




I've made some progress though, So right now it works  if I set Moodle to open a new window or use the existing window, however it does not work if i use embedded content.

I feel like i'm very very close to solving this, thanks!

Cavin

[Dietmar Zenker]

Hi Cavin,

Yes 2018-08-17 08:45:57,979 | INFO | (LtiLaunchAuthenticationHandler:221) - Returning user with 3 authorities

these are good news!!

 

I've made some progress though, So right now it works  if I set Moodle to open a new window or use the existing window, however it does not work if i use embedded content.

This behaviour is quite weird... it should also work in embedded mode. What happens if you open the embedded frame in a new tab or window?

Maybe this is a proxy related issue (rewrites etc.) - I do not use a nginx or apache as proxy, thus I cannot reproduce that.

Greets,

Dietmar

[Cavin B.]

Hi Dietmar

Opening the embedded launch link in another tab works...

I'm not sure how to address that.

Thanks,
Cavin

[R. Schneiderhan]

Hi Cavin,

just a short question. Where you able to fix this issue? What was the solution?

Thanks a lot in advance.

Raffaela