I can see the chat log. For one of the first times ever, it loaded on the first try too. But it loaded blank and I had to click "Next" before anything populated - but after hitting next, every day now populates correctly.

That honestly does not surprise me. Chat log is pretty bad (basically all of the original code, with a few modifications and a "better" GUI).

Let me know if you need any info on the code behind it, I have some limited knowledge.

Could use a way to delete my own posts.

Early last year.

I just clicked the "Mark all read" link in the Quests folder and got an odd error.

This site can’t provide a secure connection

holyworlds.org sent an invalid response.
Try running Windows Network Diagnostics.
ERR_SSL_PROTOCOL_ERROR

Hitting reload did nothing. I had to manually enter the URL to come back to HolyWorlds.

It looks like the "tech team" is finally rolling out the (long-requested-on-my-part) switch to serving the forum over encrypted HTTPS instead of clear-text HTTP, but the one glitch I've noticed is that anytime there's an internal redirect (such as in the login process, following a link from a topic-reply notification email, after posting in a thread, and yes "mark all read," if I'm coming from an HTTPS page it tries to redirect me to something beginning with https://holyworlds.org:80/, which is to say HTTPS on the ordinary-HTTP port, and so I understandably get an "SSL protocol error" (the same as Lady Sparks, I expect, with any differences stemming from a different browser and different operating system). But except for one topic-reply notification email earlier today (which had https://holyworlds.org:80 URLs in it, which then redirected to other ones even after I removed the :80 ...), I've only ever seen HW over HTTPS when I've edited a URL by hand to get me there (for testing purposes and on general principles); Lady Sparks, I wonder how you got there.

(I also noticed, last time I checked a month or so ago, that there were still a few page elements included by explicitly HTTP URLs, instead of either protocol-agnostic (href="//domain.tld/path/to/object" or HTTPS-specific URLs.)

I just had the topic-reply notification email with https://holyworlds.org:80 URLs in it. Funnily, those were working for me yesterday...

Edit: and after I hit submit on this, I got redirected to that same error page. But apparently my post did actually go through.

Removing the "s" from "https" let me see the note in the e-mail, and then access HW. Removing the ":80" did not.

Once in the HTTP view I can look at active topics and reply, etc. Maybe reply; if you see this it worked.

Coincidentally, the topic-reply notification of your post in this thread had such erroneous URLs. (But Domici's didn't. Weird. )

The HW forum software always uses that sort of redirect after posting a reply to a topic (or editing a post, or creating a new thread, or ...), and has for a few months (since not long after the site came under new management and the code thus came back into active development). I'm more aware of this because I have the "ask me every time a site wants to redirect you" setting enabled in Firefox . What's new is that the site is reachable using HTTPS and the redirection code adds a "port 80" specification to the redirection URLs, which is harmlessly redundant for HTTP but always an error unless you really know what you're doing for HTTPS. (So you didn't get redirected to an error page, the way some sites redirect you to a dedicated "that's not a page on our site" page when you try to visit a page that no longer exists, just to an address that your browser (sensibly) refused to open on security-misconfiguration grounds.


In my experience, there's always been at least one redirect between the URL in a topic-reply-notification email and the actual page (as you'll notice if you ever open one in a browser where you aren't logged in to HW, since it'll make you log in before showing it). If you remove the :80 from the first URL, that redirect just adds it back. I expect if you kept removing it every time it appeared, you'd eventually have gotten through---but going back to HTTP is indeed the easiest workaround.

The http to https transition in notification e-mails just happened to me between 0928 and 0950 EST 25 Oct 2017. I usually stay logged in to HW even if not here.

Just wanted to let everyone know that Joel has been reading this thread. This is all Greek to me, but I didn't want y'all to think the dev team was ignoring you just because they're the silent nerdy types.

Another silent nerdy type nods in agreement...

Hey all! I just wanted to let you know this is now a resolved issue...

This is the first time I've logged in for a while, but I immediately noticed the SSL certificate (whoop!) aaaaand... the redirect. The forum software has some security settings that need to be configured for use with SSL, those have been updated accordingly.

You are sweetheart! Thank you for your diligence.

Since the HTTPS-redirect bug was fixed (if not before, but in any case thank you for fixing that!), the forum feature that wouldn't let a reply be posted to a thread if someone else had done so since the user last viewed that thread without explicit approval seems to have stopped working. (Thus there's been some unintentional echoing going on in this thread, for example.)

Thanks for the report!

I have been unable to replicate the issue whatsoever... Just to clarify, you are saying that someone will post while you are writing and you are not asked to verify if you would like to post?

Yes. In the thread I linked, at least twice I clicked [reply with] "quote" on the bottommost post in the thread, wrote my reply, clicked "Submit," and was redirected to the thread, where I saw at least one other post between the post I was replying to and my reply.

Okay, thanks for the report! I’m going to continue trying to replicate the issue and see what I can do.

For about 5 minutes just now, Holy Worlds completely shut down on me.

Error 502 Ray ID: 3c589661f90d58af • 2017-11-29 21:16:20 UTC
Bad gateway

I had Joel looked into it, and he said the master server restarted to install updates. Of course now he's grumbling because it wasn't supposed to "shut down the containers" with it, but you know. Thank you for reporting this and saving the error code! That's very helpful!

When archiving a couple of threads today (i.e. using the moderation tools to move them to the Archive rooms), when the move completed, the browser tab got stuck on a blank page instead of redirecting to something that was recognizably HW. I tried manually refreshing (I mean "clicking on the URL bar and pressing Enter"), and got an error from that. I didn't think to save the URL or error the first time, but the second time, the URL was and the error was

Brought this to Joel's attention. Thank you so much!

With the browser I prefer to use for links in notification emails, which I admit is not the most compliant (I have to use a "Git live" version to get SNI support, which I need to read HW over HTTPS at all, for example ...), the links in notification emails (of the form https://holyworlds.org:443/fantasy/viewtopic.php?f=FORUM&t=TOPIC&p=POST&e=NONCE) redirect to the URL https://holyworlds.org:443/fantasy/https:///, which is of course rendered as a 404 "page not found" page. If I manually remove the :443 from the URL, everything works fine. Since AFAIK "port 443" is supposed to be the default for the HTTPS protocol, can links in notification emails omit the port number?

(I also note that the "go back to the homepage" link on the 404 page is to http://www.holyworlds.org; if I were in charge of it, I would make it either always HTTPS or matching the protocol the visitor came in on.)

(Oh, and It Would Be Nice if there were a BBCode tag in the palette above this post-edit box that would give me a monospace effect with at least a little more visual distinction than "font=monospace", but that would be inline, unlike the "code" tag.)

I can promise you that 99% of what you're experiencing is the result of many already known bugs. I'd be very reluctant to find a way to remove port 443 from the URI because it might just break something else. I believe it's a configuration option and someone set it to put a bandage on a different problem.

And the "go back to homepage" problem is likely from before we even made HTTPS a thing on this site and most of the links were being hardcoded, in fact, I can guarantee that.

Anyways, I'll see what I can do once I can find the time. It will likely require we escalate the site upgrades.

I believe the port should now be all set, please let me know if otherwise. For some reason phpBB was configured to think that that the web server was running on another port, so it was trying to enforce port 443.

The only place URI’s are hard coded are in the error pages and more or less the Anduin bar. Everything else is templated by phpBB.

The error pages are all raw code and apart from the phpBB application. This would be a very easy fix to initiate, though really, I recommend we be redirecting all traffic to SSL.

Actually, there is more site content using non-SSL than I think you're giving it credit. Particularly there's a lot of hard-coded URLs for resource files and it's causing HW to fail the Chrome HTTPS validation. So your fix works for now but we're going to have to eventually do more if we want to make SSL the standard.

Are you talking resources such as images, scripts, etc. loaded relatively? If you have a site wide redirect to SSL, that’s gonna be a non-issue.

Yes, I am. However, I disagree. Chrome will still identify that the URLs are hardcoded using non-SSL, regardless if the server is redirecting or not. Besides, redirects lag loads and put more work load on the server. As kingjon said, the URL should be coded using the protocol the visitor came in on - this is conventional web design. And this should be the preferred method as to future proof the website for whatever new protocols are one-day introduced.

Joel, this is basic web developement. The phpBB URIs are not hard coded with a protocol (in this case because they are relative) hence the browser tries to load it first over the current protocol. Because you are not forcing users to SSL (one could go to http://holyworlds.org/fantasy over an insecure connection) the browser is not being redirected, hence they are getting loaded insecurely.

Further, the browser will cache redirects, especially the permanent one an insecure to secure redirect should be.

We don’t want anyone coming in here over an insecure connection, period. Let’s get a permanent redirect up, why wouldn’t we?

Joel, on further research, there are only two items being loaded insecurely and these are the before mentioned Anduin resources (found in the Anduin bar CSS) and Anduin bar code.

This is a really simple fix. I don't have access to HW web files anymore, but can guide you if necessary.

I'd still advise you to put up a permanent redirect from http to https on all of HW.

Resources being loaded over insecure connection has been resolved by using the phpBB template variables provided us.

I recommend fast tracking a redirect from insecure to secure connections.

I was recently asked why this thread was locked and I wanted to provide some context. This thread was locked in favor of using the new "Report a Bug" feature located in the top navigation bar. This feature will post your issue directly to the HolyWorlds' GitHub Issue Tracker (https://github.com/PenoaksDev/HolyWorlds-Issues/issues) and I will receive a direct notification via e-mail. Please report your issues there and I will investigate them at my earliest convenience. If all else fails, please feel free to contact me directly via Discord, Facebook, or at [email protected].

Thank you for your dedicated patronage!