[_GamerX]

this plugin will open original Motd window as connect motd?

[Byte]

Originally Posted by _GamerX this plugin will open original Motd window as connect motd?

No I believe the original MOTD is different and doesn't use the VGUIMenu usermessage.
It should work properly though with motd.txt

[nosoop]

Originally Posted by Byte No I believe the original MOTD is different and doesn't use the VGUIMenu usermessage. It should work properly though with motd.txt

Turns out the normal MOTD in CS:GO and TF2 (and likely other games) also use VGUIMenu and an info panel; however, they use the MOTDPANEL_TYPE_INDEX type and set the msg to motd.

Originally Posted by _GamerX this plugin will open original Motd window as connect motd?

This plugin only affects hooked messages that use the MOTDPANEL_TYPE_URL type, so CS:GO's original MOTD panel isn't used or modified. However, it does toggle sv_disable_motd, so the default MOTD window will also be displayed when players connect.

[AwesomeX]

I can confirm this fixed my MOTD/WebShortcuts issues that have been plaguing my TF2 server for more than a year.

Thanks a bunch for making this.

[mlov420]

I've been having some strange issues with the latest version. When I upload the web portion to my website (which I've been using with previous versions of this cache buster for months), I get a 404 error. My website does force HTTPS, but even changing http to https on the motd_proxy page in the script doesn't fix it.

All other versions work fine on my website, it's just 3.1.2 where I'm having this issue and it's only with the motd_proxy.html page. Any idea why?

[nosoop]

Originally Posted by mlov420 I've been having some strange issues with the latest version. [...]

What version were you using previously, and is it for popups or not (i.e., using CS:GO)?

The script's check for http is only to check for URLs in the pre-version 3 $PROXY_PAGE/#$URL format for backwards compatibility reasons; as of version 3 the plugin uses a URL params-style of hash in $PROXY_PAGE/#url=$ENCODED_URL format.

An HTTP 404 (file not found) on the web portion itself suggests it's an issue with your server stack, which I assume shouldn't be an issue given you've had the proxy page on your site before.

Are you sure it's definitely a 404? If so, make sure your permissions are correct on the file and your server configuration is serving that file correctly; that's outside the scope of this plugin.

To double-check, make sure the page is available by using your normal web browser with the following URL:

https://example.com/path/motd_proxy.html?v=3#url=https%3A%2F%2Fhstspreload.org

Replace the example.com path with the path to your proxy page, obviously. Any other URL-encoded URL will do, this is the first one I could find that isn't iframe-restricted and renders fine on the black background of the iframe.

If you open up your browser's developer tools (F12 on FF / Chrome) and make the request, you should see something like the following:



A status 200 on your proxy page means it's working just fine, and your issue is likely in one of the sites you're trying to access.

Set vgui_workaround_debug_spew to 1; this will print out the URL the plugin is sending to the client whenever it rewrites a page. Check those URLs in your normal browser.

One thing I can think of since you mentioned forcing HTTPS is that mixed active content (attempting to request an HTTP-only page) will display a warning in the console tab and make no request to the page.

You'll have to replace any hardcoded HTTP requests in your own plugin(s) to HTTPS or set up your site to serve the proxy over HTTP; the browser won't do redirects for you for security reasons (because some malicious person could hijack the insecure connection).

Also, check the URL configuration (configs/vgui_cache_buster_urls.cfg; some URL prefixes don't work anymore).

If you're still having issues, I'd be happy to check when I have the time; send me a private message with your proxy URL, a URL that it fails on, and a copy of your URL config. Optionally, send me a copy of the plugin's debug output.

[hannes96]

It seems like Valve fixed this bug. At least everything is working fine for me again in TF2 without running this plugin.

[nosoop]

Confirmed; looks like the same-domain issue was fixed — maybe with the latest Steam update, considering it affected most games.

If you're using this plugin just for the same-domain fixes, you'll probably want to uninstall it after some time in case people are not up-to-date for some reason (if they ignore Steam's update nags, for example).

If you're using this for pop-ups (CS:GO or opt-in for other games), I'll be pushing out an update shortly to ensure pop-ups can still run even if the plugin is configured to not use proxies for all pages (since the delayed load isn't necessary anymore) and edit this post. The new method will still use the proxy's popup functionality, but will avoid applying iframe / delayed load workarounds.

The current workarounds will remain available for backwards compatibility purposes, even though they're effectively obsolete.

Edit: 3.1.4 has been released, with the following changes:

• Popups will set the underlying panel's show value to false. This prevents the default panel from being displayed (mainly in non-CS:GO games, but should also prevent it if a CS:GO update enables the built-in MOTD panel again).
• New URL configuration option: proxy_popups. Only applies the proxy method to popups (implicitly enabled in CS:GO by default, otherwise must specify x-vgui-popup or use the appropriate include function); other pages will be passed through. This is intended as a popup-supported version of the none option, which will never do any processing.

Important note: There is a known issue with the Steam Client beta (with the new chat interface) where opening new popup windows does not work on any game. No known fix at the moment; you'll just have to sit tight until a workaround exists (which I would be happy to implement) or until Valve restores this functionality.

[yodog]

Any fix?

[nosoop]

Originally Posted by yodog Any fix?

• For CS:GO users: Not that I'm aware of; Valve seems to have done a good job of locking down MOTD panels on the client's side. If anyone happens to discover a workaround I'd be happy to merge in any changes to make it work, but I'm not going out of my way to look for one (CS:GO support was originally a collaborative effort).
• For other games: You probably don't need this anymore, unless you're using it to implement pop-up panels, in which case that functionality seems to be working with the latest Steam Client (at least in TF2).