Showing results for 
Search instead for 
Did you mean: 

1 March: HTTP support is deprecated in Canvas Mobile apps

3 10 899

We are committed to security and protecting data. Security is not a new thing and it is not my goal to describe it in this post. If you are interested to learn more, please navigate to our Instructure Security page.

Effective 1 March 2021, we will no longer enable http traffic for any authentication providers in all Canvas mobile apps. This update means we’ll only allow communication over https protocol.

If instructors in your institution are using embedded content that is not secure, it cannot be viewed in the mobile apps. Please confirm any external content embedded within Canvas is hosted on a secure site.

Adventurer II

Hello - I have two questions:

  1. Does this mean that any hyperlinks on a wiki page, assignment, etc. that use the protocol http:// will cease to function within the mobile apps? 
  2. Should this development be listed on the roadmap? 



Is there an administrative reporting tool in Canvas that can locate any links that will no longer be allowed?


Is it possible to use the link validator tool to detect the http links inside the course content?

Surveyor II

Following, I'm interested to know what the plan for institutions should include. 


All the embedded content which works in the CANVAS website will work on mobile too after this change. Modern browsers block the mixed content already (Mixed content means for example if you try to load http resource on a https site). 


1. It only applies to the embedded content, if the resource (image, video, etc.) is loaded into the canvas content. If you have links in the content which navigate away from canvas they will not be blocked, since they'll leave the canvas site.
2. This is not a new development just a configuration.


It is a very good idea. Although even today, the mixed content is blocked by the browsers, so anything which is visible on the website will be visible on the mobile. Anything which is not loaded into the website today, will not be loaded on mobile (after the change)


No unfortunately not. The link validator does not check for mixed content only shows the broken links. There is a room for improvement here.


Any content which works in the web browser today will work in the mobile apps after the change. 


A few other questions have come up....

1. What is the error end users will see?

2. Is there any proactive way for an institution or instructor to figure out all links using HTTP?



1. The http content will not be loaded, so the user will not see that. If the CANVAS is running on https (which should be the case independently who does the hosting) then on the web site today, this works very similarly. Any http content is blocked by the browsers and not loaded. You see there should be a content there but it is not loaded because of the mixed content policy of the modern browsers.

2.   The easiest what you can do is to make sure that your URL starts with https:// and all the courses/assignments are loaded correctly in the web browsers. Then you'll be safe on mobile too. The content that will not load on mobile is not loaded by the web even today, so it is enough to consider those cases where the content is not loaded correctly in the web browser today.



I'd just like to support @ramsden and @anagui81 in the idea that there are ways Canvas can help us support the many users who may not be aware their content is already being blocked.

An admin reporting tool and a minor update to Link Validator would both be very valuable.

Community Team
Community Team

@gretchen the mobile apps pull the same content that is in the Canvas web. An enhancement to the link validator would be done by the web team.

Enhancements for this feature can be mentioned in our Idea Conversations page. I found a related conversation that may be what you're looking for and you can add your comments: Link Validation - Canvas Community.



Adventurer II

Hello - we used Canvas Data to search wiki page and assignment, etc. content for the iframe tags and the http protocol within.

I am happy to report that this was a non-issue.