Page MenuHomePhabricator

canonicalurl magic word always defaults to *showing* insecure
Closed, InvalidPublic

Description

Author: brian.mcneil

Description:
I've tested this in the Wikinews sandbox: https://en.wikinews.org/wiki/Wikinews:Sandbox

If I put {{canonicalurl:Main Page}}, the displayed link states "http:// ..." But, the actual provided link is https://

The problem came to light when trying to implement code to conditionally offer a link to the secure version of the site.

I note there is bug 38875, asking for {{CANONICALSERVER}}; I'm none-to-fussed how I can test for a page having been loaded over https://, a {{PROTOCOL}} magic word would be nice, but labelling a link as http:// when it is https:// is just plain wrong.


Version: unspecified
Severity: normal

Details

Reference
bz41237

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:04 AM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz41237.
bzimport added a subscriber: Unknown Object (MLST).

brian.mcneil wrote:

Screenshot showing access via https, with canonicalurl being parsed and displayed as-if an http llink

This is likely a bug with far-wider impact than simply the canonicalurl magic word incorrectly being displayed with the wrong protocol.

However, the problem I was attempting to solve which highlighted this is obtaining the actual protocol a user is accessing via.

Attached:

Misleading_protocol_displayed.png (672×1 px, 104 KB)

This is by design. canonicalurl returns something canonical, and http:// is configured as the canonical one.

brian.mcneil wrote:

(In reply to comment #2)

This is by design. canonicalurl returns something canonical, and http:// is
configured as the canonical one.

Okay, then how does one query which protocol a user is accessing via?

(In reply to comment #3)

(In reply to comment #2)

This is by design. canonicalurl returns something canonical, and http:// is
configured as the canonical one.

Okay, then how does one query which protocol a user is accessing via?

There isn't a way to do it in page body AFAIK. Otherwise it splits cache. See bug 31531.