Celebrate Excellence in Education: Nominate Outstanding Educators by April 15!
ORIGINAL ISSUE, AS IT STILL STANDS — The Canvas Google Apps LTI authorization is failing on me in Chrome in one course (not others), and observed with faculty. Anyone else? Workarounds?The chat with Instructure support helped determine that it worked in Firefox but not Chrome. They suspected it may have something to do with being logged into multiple accounts. His boss suggested that the Google Apps LTI might need to be re-setup (by our Admin).
Here's a screencast of the issue: Canvas Google LTI failures - YouTube
More troubleshooting:
Note:
Final bit of troubleshooting:
Solved! Go to Solution.
@johnmartin I haven't used Google Apps LTI, and would be interested to know more about what you are experiencing.
Please post back with any info you learn.
Thanks @jomontuori . Yes, this has always worked for me. The problem is that we'd have to explain this to 60,000 users who are used to not having a problem using multiple Google accounts — they don't have to do this with other Google API integrations; just Canvas. This special exception for Canvas, imho, should be removed as a matter of removing barriers for learning.
In the meantime, the other workaround — that doesn't require users to change ingrained behavior to access course content — is to use iFrame embedding.
I surely hope Instructure can recognize that adding this barrier for student-access to content is a step backwards that should be done correctly.
thanks!
John
Hey Everyone - I have the solution! At least it worked for us...
This does involve going into Google Admin and making a change to the Sharing settings for the Drive and Docs app settings.
1 - Go here
2 - Scroll to Option 2, then number 2 "Go to Apps > Google Workspace > Drive and Docs"
3. Make sure you are in the Sharing Settings, then choose the proper OU that you would like to make the change for.
4. The setting that needs to be on is: "When sharing outside of "your institution name" is allowed, users in "current OU" can make files and published web content visible to anyone with the link.
Thanks @scottdennis ! I'll keep waiting and hoping (and occasionally bugging) .
Hi @johnmartin ,
I am not modeling best practices, I have not read through all of these comments, but I wanted to respond.
The Canvas-Google 'marriage' is a very fragile one.
When teachers or students report that they are unable to Authorize with Google, I tell them to go to google.com and sign-out of all google accounts. I then have them log into only their school google account.
After we have followed these steps there have not been any issues connecting. (Unless someone signs into another google account.)
I suspect that is why it works in incognito.
I, myself, have multiple google accounts signed in, and don't have an issue, but I know that if/when I do run into that issue I just have to sign-out of all accounts, re-authorize, and issue resolved.
Thanks @jfrielich_ls ! Yes, it's fragile, and also mysterious! I keep hoping that if they're unable to fix it, or if it's too low a priority to fix it, Canvas will at least add an error message telling users that useful path (rather than the cyclical "Please click "Authorize" to try again"). A "just-in-time" error message directing them to a solution is far better than a message from me because I only (sometimes) hear about it after the instructor has abandoned the practice because of too many complaints from students. It would be interesting to see a count of how many "Try Again" error messages are generated each day/week/month/since-the-LTI-was-introduced.
John, I finally felt your frustration first hand; though it was not your issue it was a panic over authorization failing. This thread saved me.
ysmalls you saved me here, thank you.
Canvas Google LTI integration also does not work with Opera browser (at least not for me — others?). The Authorization loop (still with no feedback or direction on what to do) continues to loop.
Sigh.
Hi John,
Just in case it is helpful, here is a list of the browsers we support: https://community.canvaslms.com/docs/DOC-10461-supported-web-browsers
Yup. Just saying that since I log in to Chrome with my personal account, and Google LTI is broken for that, I hoped to use Opera. But nope.
Also, still no indication in an Authorize Loop error message directing the user what to do...
(sorry for the negativity; it's Friday of our Canvas Week and I've been running into so many errors and trying to explain so many workarounds to overwhelmed and grumpy faculty that their stress has rubbed off on me. I really want to love Canvas, but there are so many frustrations that seem to be easily addressed but largely not.)
We are experiencing the same level of "explaining" and "work-arounding" and frustrated students and staff. No integration should be this poor with no fixes in sight.
We have experienced the same problem, to the point where we feel we may need to disable the Google Apps LTI. Each time I present this as a feature to teachers and students, I am overwhelmed with support tickets. The workaround I have found that works often is to create a second profile in Chrome, and log that profile into the school account only. But trying to explain profiles in Chrome to every student is pretty frustrating.
I understand that Instructure is working on this. I just wanted to add my voice to those who are also experiencing problems with the LTI.
Robert,
We are not a Google shop, but our faculty tend to prefer Google to Office 365. As you probably guessed, we are a Microsoft shop. Do you think Office 365 will run into the same authentication issues we see with the Google LTI?
The Office integration LTI is [also] pretty crappy (sorry, it is). I think Canvas is just struggling overall in building integrations.
Can't say that you are wrong here, but some blame is on the MS side too I think.
Oh, @dwillmore , I have no doubt of that!
I use the Dropbox integration to create shared links inside of my course. My students also have the ability to submit assignments from their Dropbox. Microsoft actually integrated Dropbox natively into Office 365 allowing me the ability to edit and save right back to Dropbox without having to edit the course link in Canvas. Maybe not as full featured, but it works for what I need it to do.
We've been experiencing the same issue, where clearing the cache or logging out of all Google accounts does seem to clear it up, but it only clears it up for that session. The bigger annoyance is having to authorize the app every time you use it. Weirdly, one of my colleagues hasn't had this issue. She simply got the app to authorize the first time and it's stuck ever since. She's working on a Chromebook and using Chrome. However, myself as well as many of our students can't get the authorization to stick. This seems to be especially present when using Chrome on a Mac. Not sure why, but that's where more of the issue tends to lie as of now. Just throwing my additional concern and frustration about an app from such a big name like Google.
Hi everyone--forgive me, I haven't had a chance to read through the entire thread, but before we hit the weekend I wanted to add the testing I've done. Here's what I've seen:
Almost all of my testing has been done with @gmail.com accounts because I wanted to be using accounts without a lot of technical baggage. I’m also using virtual machine snapshots created immediately after Chrome was installed (and the VM was created) so there’s no device-side user data whatsoever.
Here’s one test I did: https://iu.box.com/s/yo90n2fpgrxmsmmlewpxqsgnbpby60rl (you should be able to play this video in a browser, wouldn’t recommend downloading it)
1. I demo that I’m using a brand new, up-to-date version of Chrome. This is on a new, completely unused virtual machine. Cache and cookies are cleared, Chrome is reset.
2. 0:54 – in an incognito window I sign into scmctest1@gmail.com. I demonstrate that I haven’t authorized the Google Drive LTI to access that account yet.
3. 1:53 – I’ve reclosed the incognito window and reopened it. I log into Google with scmctest3@gmail.com and demonstrate that I haven’t authorized the Google Drive LTI to access that account yet.
4. 2:29 – I sign into Chrome with my scmctest1@gmail.com account.
5. 2:58 – I log into Canvas with scmctest3@gmail.com.
6. 3:25 – I demo that I don’t have any Approved Integrations listed for scmctest3@gmail.com in Canvas. I also don’t have Drive listed under Registered Services.
7. 3:40 – I attempt to create a new collaboration. I’m asked to authorize my account.
8. 3:45 – I click Authorize and am prompted to either select the scmctest1@gmail.com account that I logged in with at step 4 or click “Use another account”. I click “Use another account”, wanting to log in with scmctest3@gmail.com instead.
9. 3:55 – I enter scmctest3@gmail.com’s credentials and choose to allow Google to access the account.
10. 4:10 – I receive an “Authorization failed” error.
11. 4:18 – I show that as far as Canvas is concerned (via Settings), I’ve successfully authorized a Google account.
12. 4:28 – I show that as far as Google is concerned, I haven’t authorized any access for my scmctest1@gmail.com account.
13. 4:34 – I show that as far as Google is concerned, I’ve authorized LTI access for my scmctest3@gmail.com account.
TL;DR: The “Use another account” prompt does not work. Canvas Support has indicated that this is expected behavior.
Another: https://iu.box.com/s/8otz2fn82eyebamk700x0t567otv7eai
1. Same as above: brand new, up-to-date version of Chrome. New, unused VM.
2. 0:41 – I display the Google sign in screen to show that I’m not logged in.
3. 1:06 – I open an incognito window and log in with scmctest3@gmail.com. I show that I haven’t authorized any apps to access that account. I close the incognito window.
4. 1:38 – In a regular browsing window I log into Chrome with scmctest3@gmail.com.
5. 1:57 – I show that I don’t have any Approved Integrations listed Canvas-side.
6. 2:10 – I open Google Drive in a course and authorize my scmctest3@gmail.com account.
7. 2:35 – I receive an “Authorization failed” error. I attempt to authorize the account again and this time Google Drive loads as expected. Refreshing the page would have also worked.
According to Canvas Support, this is expected behavior, and could’ve been avoided if I’d logged into my account at google.com before trying to authorize it in Canvas. I did try this later (logging into Google first) and still ran into the auth error, and it was suggested that I add Google Drive as a Registered Service to work around it. That actually worked, but apparently shouldn't have given that the documentation indicates that you don't need to do it.
All that aside, I'm also hearing from students who are having to request access to docs that they were added to via Collaborations. They're actually added to groups in Canvas and their groups are added to the docs. All the docs were created the same way and the same groups are used, but the students have to request access to some of the docs and not others (in the same browser, in the same session). Has anyone else run into this? I haven't figured out what's causing it yet.
Hi @emihunt ,
Thank you so much for going down that rabbit hole that you did! I hope that Instructure will begin to see what a problem this is, and put more resources towards fixing it (soon, please!).
In the mean time, I have been actually actively discouraging our 4000 instructors and 50k students from using any of the Canvas LTI tools or Google Collaborations because of the types of issues that you're seeing (which cause instructors, students, and support folks so many headaches!).
Instead of Collaborations, which open to a blank document, I distribute Google Doc worksheets with prompts via the Google Doc "/copy" trick. This trick prompts —with a single button — whoever clicks on the link to create a copy of the document (with prompts for them to answer) in the student's own Google Drive. I can assign this as a Group assignment if I want students to collaborate on it. They share back with me. It's not as nice and smooth as Collaborations could be, but much nicer than it currently is.
To do this, I just take the URL of an "Anyone with the link can view" doc, and replace the "/edit..." text with "/copy". For example: "https://docs.google.com/document/d/1Cx9EitFvsh-Vz3AQ1XY32cNdPvfniz814IPMIxXX2EQ/edit" becomes "https://docs.google.com/document/d/1Cx9EitFvsh-Vz3AQ1XY32cNdPvfniz814IPMIxXX2EQ/copy". Of course you can also use the link tool to change the text to "Active Teaching Lab Schedule".
Naturally, our preference would be for the Canvas tools to work, but since there's been no forward movement on these issues since the tool was released last January, I'm researching workarounds.
Please keep sharing any more insights and workarounds you find! Thanks!
The Google LTI is the only LTI that I have had this difficulty with at this time, and we use many integrations. We did have some problems when students went to a publisher's site to register for course material instead of going through Canvas to the publisher's site, but that has resolved itself with training.
Have you seen this type of problem with other integrations?
The two primary issues we're encountering with the integration so far this school year are:
1) Long processing delays when students have selected an item in their Drive via the Google Drive tab (assignment submission option in Canvas) and eventual failure to submit. Instructure has suggested this might be related to poor network capacity, so I've reached out to the affected teacher-users to inquire about typical connectivity in their classrooms and will be following up with support.
2) A few instances of Google Cloud Assignments being submitted by students only to reveal a capture error when the teacher attempts to view in Speedgrader. While this occurred to me and the adults I was working with on Friday morning, by afternoon submissions from later participants were being successfully captured and were visible in Speedgrader. This has been escalated to engineering support in Service Cloud.
In nearly all the cases of Google Authorization failure, we have solved the issue by having students clear their cache.
I was so happy to stumble across this post this morning! I feel your pain regarding the Google LTI integration. It's our first full year of integration and I have teachers asking to go back to Google Classroom for the headaches they've been having! I was hoping to NOT have to go back to the Google Doc edit/copy URL changes.
Our Language Arts teachers especially are asking to be able to show mark-ups on the submitted Google Doc, so the students can continue editing the same doc. It would be nice to be able to do this without the students sharing the document with the teacher. What's the point of the LMS then?
@kblack , can you help us?
@rislis , do your students use their own laptops or school-issued ones?
School issued Chromebooks. 1:1.
Thanks @rislis ! That's useful information! As far as I've seen, there haven't been significant issues for that subset of users. At UW-Madison we've got a lot less control (none) of what students use to access the content. I suspect the LTI tools were developed with your use case in mind, but were never really tested with what our situation is .
And I can imagine professors never wanting to use it again, as they run into those Google LTI issues.
Thank you for thoroughly documenting this issue @johnmartin . I work at RMIT University, which uses Google Edu Apps with various restrictions, and having adopted Canvas this year (for wider scale roll out 2018) I've only just recently encountered this problem as well. I called Canvas support in October, and the person I spoke to did not seem well briefed in the issue - simply advising me to use another browser in future. I'll try asking our admins to reinstall the LTi, and will personally advise staff to avoid using it. Please keep logging progress here, if there is nowhere else.
Honestly, my teachers would be up in arms if we didn't have this LTI available to them. While it isn't perfect, it's still better for us - especially being in a 1:1 Chromebook setting.
Oh yes, @rislis ! In a 1:1 Chromebook setting, this has got to be so valuable! My only wish is that it worked for others :smileyplain:
Is there an idea that this account conflict is affecting people with Google Edu domain accounts? I'm wondering if it has something to do with it, or if it's further to do with Google Edu domain accounts with specific restrictions on them?
I imagine it's possible that some of the problems may be edu-specific, but whenever I replicated the 'authorization failed' errors for Canvas Support I used new @gmail.com accounts to rule that possibility out for them (after having initially seen the errors from my edu Google account). The issues I've seen haven't been specific to our edu instance.
Still broken as of June, 2018. Both Google Drive and Office 365 absolutely refuse to authorize in Canvas even though I see Canvas as authorized in my actual Google account. Office 365 doesn't work at all.
The only times we have any issue is if the person is logged into the browser with a different account than their institution google account or if they accidentally authorize the lti to a different account. I had one teacher who authorized the LTI to her child's student account but once we disconnected and authorized correctly all was fine.
An institution Google account is not relevant to the issue in my case. There is no institution Google account to sign in to. We're told to use our own, personal Google log-in. Office 365 doesn't work, either.
Here it is January 2019 and this is still happening. I will submit a new ticket
I've been troubleshooting it in many separate occasions since 2018. I THINK I FIGURED IT OUT. Somewhat, at least. Thanks to the video, I can also prove that it's a related problem and actually say what the fix is. I can only speculate on the actual problem though since I still don't know what scenario causes it.
Try both specifying *.instructure.com, *.google.com, and allowing third-party cookies while ensuring that any adblockers are disabled for Canvas. Suboptimal to say the least, but it looks like in specific scenarios, the cookies needed to complete the handshake for the Google Drive LTI by Canvas embedding are triggering the "third-party cookie" blocking.
So, one thing I started noticing recently is that it says "Third Party Cookies are blocked." Every single time. Which, I should also note that typically in the situations where this bug occurs, Google Drive integration (submitting assignments) is fine, but it's the Google Drive LTI by Canvas plugin (that embeds Google Drive links) that breaks and has the authorization loop. Specifically, Google Drive LTI by Canvas has to generate cookies for what I can categorize as two different site locations: Google (and related subdomains/links such as account.google.com) for authorization and Google Drive LTI by Canvas (https://google-drive-lti-iad-prod.instructure.com/). Google plugins can, simply put, be of two types - site-based, or Google-based. A Google-based plugin can only interact with whatever libraries it contains - however, site-based allows conventional programs and interfaces to be hooked up, at the cost of requiring a site location to host the app integration (in this case, https://google-drive-lti-iad-prod.instructure.com/). Hence why one can break and the other can be fine - they are implemented into Canvas in dramatically different ways even if they appear to be more or less functionally the same.
The strange thing about this is that we would do all the steps outlined (clear cookies, rebuild local profile, reset cache, etc) and it would never work. We would specifically put in an allowance for *.instructure.com, and even those that specified the subdomain and address for specific scenarios, and yet no dice. Only in this scenario, I noticed something different - it was making cookies, but it wasn't accepting ALL of them.
As to what scenario this is caused in - I still don't have enough to do more than speculatively guess, since I'm unable to reproduce the problem for further testing. It seems to be session-specific since even in private mode it functions fine. When I checked the data of the cookies, while they did note their site of origin, most of the fields were blank - my current guess is that cookies that are needed to confirm the "handshake" between the LTI and Google can be improperly generated in a scenario. While suboptimal to say the least, disabling anything that would filter or block cookie generation allows it to once again operate as intended. In this scenario, it actually triggered on a clean install of a computer, as well as Chromebooks in a group.
I want to say...that the problem is related to renewing, modifying or generating the LTI-specific cookies. As far as I can tell, the Google side of the auth isn't failing - it's only ever when the Google-side of the auth completes and the browser focus returns to the Canvas side that the auth fails. It's got to be some way that Canvas is identifying clients or identifying connection paths in some manner that errors out server-side - it almost feels like the client sends it cookie data for it to modify and return, but instead all of the fields in the cookie return as (null).
Hi, John,
I'd recommend taking a look at the latest news about Google, as they have a new LTI tool that will eventually replace the one that Canvas built: Google Assignments LTI (Beta) for Canvas Users [Course Kit]
Thanks!
Erin
To participate in the Instructure Community, you need to sign up or log in:
Sign In
This discussion post is outdated and has been archived. Please use the Community question forums and official documentation for the most current and accurate information.