Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

yourls_get_favicon_url is abused by yourls_match_current_protocol #2430

Open
tobozo opened this Issue Sep 10, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@tobozo
Copy link

tobozo commented Sep 10, 2018

yourls_get_favicon_url() seems to take for granted that PHP will always share the same protocol as the frontend server.

Problem: generated favicon protocol doesn't match admin console protocol when Yourls is behind a reverse proxy.

image

Steps to reproduce:

  1. Yourls is behind nginx reverse proxy: e.g. Apache/PHP (HTTP) <=> Nginx (HTTPS) <=> Client
  2. Visit https://my.yours.installation/xxx+ to see the stats of the xxx short URL

When these conditions are met, the favicon address to the long URL domain is generated using HTTP http://www.google.com/s2/favicons/..... instead of HTTPS, in some situations the favicon won't show up on the stats page.

Also a few warnings about mixed content can be observed in the console.

image

Would it make more sense to use a protol relative address instead: //www.google.com/s2/favicons/..... ?

Using the following code made the warnings go away and the favicons show up:

function yourls_get_favicon_url( $url ) {
        return yourls_match_current_protocol( '//www.google.com/s2/favicons?domain=' . yourls_get_domain( $url, false ) );
}

(I only removed the hardcoded "http:" from the URL)

@ozh

This comment has been minimized.

Copy link
Member

ozh commented Sep 10, 2018

Anyway the whole 'yourls_match_current_protocol' stuff is deprecated now. We should probably just use scheme-less URL everywhere (eg //url.com and let the client decide if this is http or https)

@tobozo

This comment has been minimized.

Copy link
Author

tobozo commented Sep 11, 2018

We should probably just use scheme-less URL everywhere (eg //url.com and let the client decide if this is http or https)

That stands with google favicon where both http and https are available, but there are still some http-only servers out there, and there are YOURLS plugins that implement other protocols so it could be an issue to implement that "everywhere".

@vineettalwar

This comment has been minimized.

Copy link

vineettalwar commented Sep 17, 2018

I had the similar issue, checkout #2383 . Solution for LeoColomb worked for me in that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.