The Song Fight Bulletin Board

Is there a way to get a secure connection on songfight.org? Recently my workplace updated their security policies and now I can't listen to SongFight because it's dubbed it "a security risk". Which is obviously nonsense but the messages that I get indicate that the lack of https secure connectivity is the reason.

songfight.org should support https:// URLs everywhere, but unfortunately the way the actual fight archive is set up, all music links are absolute http:// ones. It's an unfortunate historical legacy thing that would probably be difficult to fix without breaking a bunch of stuff.

Does the Jukebox's cert work for you? https://sfjukebox.org/ It currently uses only http links to songfight.org but I could probably pretty easily update it to use "protocol relative" links to songfight.org. That would mean that folks on the Jukebox using https would get https links to songfight.org. I tested an MP3 link and a cover art link on songfight.org with https and those seemed to work OK.

The SongFight.org main page and the sfjukebox.org both load, but I am unable to stream any music that's hosted on the server...which means the fight archive is unavailable. Kind of hoses both the jukebox and the main page for me. At work at least. Or as I like to call it "a quiet location where I can listen to the whole fight uninterrupted by small children" :p

The review-o-matic mirror looks to be all HTTPS, if downloading is an option for you.

https://jk.gs/songfight-download/

This was the main reason I was never able to get a Song Fight! Alexa App working, I believe. (No I never did get any further with the App and I don't even know if Amazon had saved any of my progress sadly it's been too long since I even bothered with it...) However the fact that Amazon only allowed linking to https:\\ killed the idea for me... though I at one point was hoping to get a "Alexa, Play the current Song Fight!" to work.

It might not be too difficult to change the songpage.php and index.php to replace `http://(www.)?songfight\.org/` with `/` on the various outgoing links. Or at least the mp3 and playlist links.

EDIT: wow I am so used to markdown editing now

What about just replacing "^http://" with "//" so that the links still have the domain and work from the Jukebox?

I was thinking doing the replacement at render time specifically so that it wouldn't disrupt the jukebox. // protocol-relative links are also an option but not all things know how to handle them correctly so it'd probably end up breaking stuff, and personally I'd like to see us move away from global absolute links wherever possible (but changing the archive links to be e.g. /music/floating_bridge/mcfrontalot_fb.mp3 would probably break stuff).

Also keep in mind that changes to archive data will also require changes to the scripts that manipulate the archive data; if the current fightmaster upload scripts still write out http://www.songfight.org/blahblahblah URLs to the archive then any new fights will continue to have crap URLs.

Yeah, I would prefer no one attempt to make sweeping changes throughout the archive data. Too risky. Any changes would ideally be runtime transforms of the archive data as it is formatted now.

Right. So I mean if you meant having the jukebox convert the http:// links to // links in its frontend or ingest, that'd be totally fine. I thought you meant changing the archive data.

Actually, what process does the jukebox use to ingest data from the archive? I assumed you were parsing archive.txt yourself.

Oh yeah, sorry, I was mixing things up. We'd need to have the on-the-fly regex replace happen both in the songfight.org PHP code and the Jukebox's page rendering, and the relative path would work fine on songfight.org. I could do the protocol relative thing on the Jukebox side and if that doesn't work in 100% of browser I'm ok with that.

Browsers all support protocol relative links fine, the problem I was worried about are random podcast clients and whatever.