#2122 closed task (fixed)
Travis/GitLab/Jenkins badges not shown anymore on postgis/geos trac wiki
Reported by: | strk | Owned by: | strk |
---|---|---|---|
Priority: | blocker | Milestone: | |
Component: | SysAdmin/Trac | Keywords: | |
Cc: |
Description
As reported in https://trac.osgeo.org/postgis/ticket/4019 some badges are not shown anymore on PostGIS wiki since the recent upgrade.
I found the problem being with
crossorigin="anonymous"
Attribute being added to the img
tag. This is done by Trac itself because we surely haven't added that manually.
Example showing the fix: https://trac.osgeo.org/test.html
Change History (7)
comment:1 by , 7 years ago
follow-up: 7 comment:2 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
render_unsafe_content
is currently set to disabled/false for each environment (rather than globally). No safe_origins
is set. I've set safe_origins to *
globally and it fixed the problem (possibly raising other problems but better discuss this separately)
comment:3 by , 7 years ago
For the record, the global config change is in this commit: https://git.osgeo.org/gitea/sac/tracsvn-etc-trac/commit/6cd98916c548add96c5c69b714f863d82c66a1c4 (requires login and permission to view)
comment:4 by , 7 years ago
And here's the possible commit which changed things between previous Trac version and current:
commit 46f42cbc494991dcd3b87c63d60c48bc0020faac Merge: 9d238d0 ab581b8 Author: jomae <jomae@af82e41b-90c4-0310-8c96-b1721e28e2e2> Date: Wed Jun 14 03:22:34 2017 +0000 1.2.2dev: merge [16025] from 1.0-stable git-svn-id: http://trac.edgewall.org/intertrac/log:/branches/1.2-stable@16026 af82e41b-90c4-0310-8c96-b1721e28e2e2 commit ab581b8f99a022be5049174e100d775e051a6426 Author: jomae <jomae@af82e41b-90c4-0310-8c96-b1721e28e2e2> Date: Wed Jun 14 03:19:01 2017 +0000 1.0.15dev: add `[wiki] safe_origins` option to avoid `crossorigin="anonymous"` attribute (refs r15894) git-svn-id: http://trac.edgewall.org/intertrac/log:/branches/1.0-stable@16025 af82e41b-90c4-0310-8c96-b1721e28e2e2 commit bc37331bd5264e4de9e31284b6de91975ccc7b81 Merge: 69d4755 1e3f7a2 Author: jomae <jomae@af82e41b-90c4-0310-8c96-b1721e28e2e2> Date: Fri May 12 08:23:27 2017 +0000 1.2.2dev: merge [15894] from 1.0-stable git-svn-id: http://trac.edgewall.org/intertrac/log:/branches/1.2-stable@15895 af82e41b-90c4-0310-8c96-b1721e28e2e2 commit 1e3f7a291df40d67ec88c42ed88c42fc91ebe5bd Author: jomae <jomae@af82e41b-90c4-0310-8c96-b1721e28e2e2> Date: Fri May 12 08:17:15 2017 +0000 1.0.14dev: avoid password prompt for cross-origin resources git-svn-id: http://trac.edgewall.org/intertrac/log:/branches/1.0-stable@15894 af82e41b-90c4-0310-8c96-b1721e28e2e2
comment:5 by , 7 years ago
I believe safe_origins should be set to reflect the domains we actually want remote data to be included from, such as secure.travis-ci.org, *.osgeo.org, *.postgis.net, etc. The crossorigin="anonymous" tag mitigates user tracking an phishing attacks by causing the request to be made without submitting cookies, credentials, or other identifiable information, which an untrusted remote host may be able to use in nefarious ways.
comment:6 by , 7 years ago
According to specs, 'crossorigin' img attribute (added in HTML5) should have to do with using the image as a canvas, but not prevent its loading. See https://www.w3schools.com/tags/tag_img.asp Instead browsers are not loading the resource at all.
There are 24 trac instances under OSGeo: https://trac.osgeo.org/ - we don't want to restrict the possibility to load images from the network to an handful of "trusted" sites, and why should we trust travis-ci.org anyway ?
That said, if the servers serving the images would allow cross-origin use, as it would make sense for public badges, this problem would not exist. We can fix the ones under our control but we cannot fix the travis/gitlab-ci ones.
There seem to be a trac configuration to lits safe origins: https://trac.edgewall.org/wiki/TracIni#wiki-safe_origins-option
Any domain listed there ("*" allowed) would be rendered w/out 'crossorigin="anonyomous"' I don't know why it was working before the upgrade, maybe the default
render_unsafe_content
configuration for[wiki]
section used to be true ?