#7009 /nf/tool_icon_css doesn't preserve https for URLs

v1.1.0
closed
sf-1 (604)
General
Cory Johns
2015-08-20
2013-12-19
Dave Brondsema
No

If /nf/tool_icon_css is served from an HTTPS URL, it should try to use https URLs in its output. Or something like that, so that browsers don't give mixed-security content warnings.

Discussion

  • Dave Brondsema
    Dave Brondsema
    2013-12-19

    • status: open --> in-progress
    • assigned_to: Dave Brondsema
     
  • Dave Brondsema
    Dave Brondsema
    2013-12-19

    The call chain to generate these URLs is deep. A few key stops along the way are:

    • g.tool_icon_css
    • g.theme_href()
    • ew.ResourceManager.absurl
    • ew.core.widget_context, a StackedObjectProxy
    • which gets set by ew.middleware.WidgetMiddleware.__call__
     
  • Dave Brondsema
    Dave Brondsema
    2013-12-19

    • status: in-progress --> code-review
     
  • Dave Brondsema
    Dave Brondsema
    2013-12-19

    allura:db/7009

    All the code to generate the URLs was working correctly, we were just caching g.tool_icon_css too heavily with @LazyProperty so the current scheme wasn't being used after the first hit.

     
  • Dave Brondsema
    Dave Brondsema
    2013-12-19

    Also, this only occurs when ew.url_base and/or static.url_base are set to a different location (e.g. using a CDN) like ://my.cdn/allura/nf/%(build_key)s/_ew_/

     
  • Cory Johns
    Cory Johns
    2013-12-19

    • status: code-review --> closed
    • QA: Cory Johns
     
  • Dave Brondsema
    Dave Brondsema
    2013-12-20

    • status: closed --> code-review
    • QA: Cory Johns --> nobody
     
  • Dave Brondsema
    Dave Brondsema
    2013-12-20

    Another commit on db/7009 to fix the same over-caching issue, but this time for 3rd party Apps' icon urls.

     
  • Cory Johns
    Cory Johns
    2013-12-20

    • status: code-review --> closed
    • QA: Cory Johns