harvard-edtech / caccl

The Canvas App Complete Connection Library (CACCL) is an all-in-one library for building Canvas-integrated apps. By handling LTI, authorization, and api for you, CACCL makes building Canvas-integrated tools quick and easy. Keywords: Canvas LMS Instructure API LTI Authorization EdTech Education
MIT License
33 stars 4 forks source link

How to set up multiple launch paths? #28

Open renaatdemuynck opened 1 year ago

renaatdemuynck commented 1 year ago

Hello @gabeabrams, I added my app to Canvas, but I need multiple launch paths (course, user & admin). How do I do this? I have this in my config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<cartridge_basiclti_link ...>
    <blti:title>CACCL TEST</blti:title>
    ...
    <blti:launch_url>https://ahs-pre-web-ada-next.azurewebsites.net/canvas/launch</blti:launch_url>
    <blti:extensions platform="canvas.instructure.com">
        <lticm:property name="privacy_level">public</lticm:property>
        <lticm:options name="course_navigation">
            <lticm:property name="url">https://xxxxx.azurewebsites.net/course</lticm:property>
            <lticm:property name="text">CACCL TEST</lticm:property>
            <lticm:property name="visibility">public</lticm:property>
            <lticm:property name="default">enabled</lticm:property>
            <lticm:property name="enabled">true</lticm:property>
        </lticm:options>
        <lticm:options name="account_navigation">
            <lticm:property name="url">https://xxxxx.azurewebsites.net/admin</lticm:property>
            <lticm:property name="text">CACCL TEST</lticm:property>
            <lticm:property name="enabled">true</lticm:property>
        </lticm:options>
        <lticm:options name="user_navigation">
            <lticm:property name="url">https://xxxxx.azurewebsites.net/user</lticm:property>
            <lticm:property name="text">CACCL TEST</lticm:property>
            <lticm:property name="enabled">true</lticm:property>
        </lticm:options>
    </blti:extensions>
    ...
</cartridge_basiclti_link>

The course, user and admin routes are correctly set up in my app, but if I click the link in the (sub)account navigation, I get this error:

Cannot POST /admin

I tried several variations of the launch URL (e.g., /canvas/launch/admin), but without success. In development, I used this config:

{
    ...
    "customLaunchPaths": [
        {
            "name": "Course Launch",
            "path": "/course"
        },
        {
            "name": "User Launch",
            "path": "/user"
        },
        {
            "name": "Admin Launch",
            "path": "/admin"
        }
    ]
}

How do I configure this correctly for a production environment? Could you please point me in the right direction?

renaatdemuynck commented 1 year ago

Just found out that when I click on the extra Choose Path buttons, before I click on the button for the Home path, It isn't handled as an LTI launch (status.launched is FALSE).

afbeelding

On the otherhand, if I choose Home first, subsequent clicks on the other paths do work.

gabeabrams commented 1 year ago

Hi @renaatdemuynck

Due to the way that LTI apps are registered in Canvas (not all apps are registered, only the ones with API access), CACCL is designed to only support one launch path. The standard way of having multiple ways of launching the tool is to provide a custom parameter.

To see how these custom parameters are added, check out this lti xml builder form and use the "custom fields" area: https://www.edu-apps.org/build_xml.html

All variations of the app will still use the same launch path, but use different custom fields. For example, you could have a custom field called "type" that could have values "course" or "user" or "admin".

Once the app is launched, the launchInfo object will automatically contain a map called customParams which is a key/value map of custom parameters. Here's a link to the launchInfo docs: https://github.com/harvard-edtech/caccl-lti/blob/main/docs/LaunchInfo.md

I hope this helps!

Gabe

P.S. The custom launch paths field that you found for the dev environment is actually for a separate purpose. For self-launched apps, the user flow starts with visiting an unauthenticated path (e.g. /home/tutorials) which probably would log the user's destination, perform a self-launch, and then upon launch, redirect the user to the place they were trying to go. This doesn't seem to be the launch process that you're going for, so I would actually fully remove those custom launch paths.