KristinDarken ... no space at (@) this site's domain (whateleyacademy.net).
Question Can't access server from Fandom (the Wiki)
- XaltatunOfAcheron
-
Topic Author
I just tried to get to it from TvTropes, and it works there.
- Malady
-
Wiki: I Don't Think We're in Kansas Anymore#Part 1 , which doesn't work...
whateleyacademy.net/index.php/2nd-gen-canon/635-elrod-nagrij
VS.
Wiki: The Evil That Men Do#Part 1 , which does.
whateleyacademy.net/index.php/original-t...the-evil-that-men-do
- Sir Lee
-
Wikia/Fandom is converting all external links into https:// links, even if they are explicitly http:// links. However, whateleyacademy.net does not support https:// connections yet.
The long and short of it is that the Web is moving towards https, and sites that don't support it are increasingly treated as second-class citizens. Browsers have been popping warnings about our unencrypted logon forms for a while now, and they might eventually disallow unencrypted passwords altogether (I think I read something a few months ago about this being already on Chrome's roadmap)
Supporting https is a pain, but it appears that the pressure towards compliance is increasing.
- XaltatunOfAcheron
-
Topic Author
There are ways to do it in sort of a compatible way (check for https:// first, then the port 80 for http://) but either Fandom decided not to do that, or it decided that people had enough time to convert and removed the compatibility.
- Malady
-
- XaltatunOfAcheron
-
Topic Author
Malady wrote: But, why is it happening on "I Don't Think We're In Kansas Anymore", but doesn't happen on "The Evil That Men Do"?
As a retired software developer, I can give you an answer: Fandom's system is FUBAR. They're engaging in a total rewrite based on a current version of MediaWiki, it's so bad.
With that kind of a mess, glitches are inevitable.
- Sir Lee
-
- XaltatunOfAcheron
-
Topic Author
Sir Lee wrote: It happens in "The Evil That Men Do" for me, too. There are any number of possible reasons for the inconsistency. Most likely, on a large site such as Fandom, we are seeing out-of-sync mirrors. Depending on where you are located and which particular page you are opening, you are directed to one server or another. I'm getting all pages (so far) from the "updated" servers, but Malady might still be getting a few pages from a server that is missing the latest updates.
The Evil that Men Do is still going through OK for me, although that might be a locally cached copy.
Just cleared history - it's still coming through fine.
- null0trooper
-
Malady wrote: But, why is it happening on "I Don't Think We're In Kansas Anymore", but doesn't happen on "The Evil That Men Do"?
Because the links on the page for "The Evil That Men Do" haven't been "fixed"
I.e., The urls are still http:, pointing to port 80 here, vs. https:, pointing to port 443.
Forum-posted ideas are freely adoptable.
WhatIF Stories: Buy the Book
Discussion Thread
- XaltatunOfAcheron
-
Topic Author
null0trooper wrote:
Malady wrote: But, why is it happening on "I Don't Think We're In Kansas Anymore", but doesn't happen on "The Evil That Men Do"?
Because the links on the page for "The Evil That Men Do" haven't been "fixed"behind our backsfor us yet.
I.e., The urls are still http:, pointing to port 80 here, vs. https:, pointing to port 443.
I just took a look at Kansas, and all the links are http://, not https. They're doing something other than changing the text on the page. They're almost certainly changing it in flight somewhere in their software.
- Kristin Darken
-
Fate guard you and grant you a Light to brighten your Way.
- Kettlekorn
-
- XaltatunOfAcheron
-
Topic Author
Kettlekorn wrote: The internet is aware of that issue and has been working on solutions. In particular, letsencrypt.org and certbot.eff.org come to mind. The former is a free, automated certificate authority, and the latter is one of several client programs that can be run on a server to obtain and install a certificate from Let's Encrypt and then be put in a cron job to automatically update that certificate every couple months.
Getting a certificate is the least of the problems. As you say, it's pretty straight-forward these days. It's the rest of the work that needs to be done that's the problem. That includes checking out the basic frameworks, plugins, configuration files and probably a host of other things I've probably never heard of and don't want to know. My last brush with system administration was on IBM mainframes in the 1970s, which is not particularly relevant to this problem.
Kristen's comment about it requiring a full-time unix system administrator is not that far off the mark: the knowledge base needed to do the job efficiently is that of someone who has been a full-time unix system administrator. Otherwise it's by guess and by golly, and would take a lot longer and create a lot more frustration.
- null0trooper
-
XaltatunOfAcheron wrote: Kristen's comment about it requiring a full-time unix system administrator is not that far off the mark: the knowledge base needed to do the job efficiently is that of someone who has been a full-time unix system administrator. Otherwise it's by guess and by golly, and would take a lot longer and create a lot more frustration.
Not really. Installing the signed certificates (if the hosting company hasn't already taken care of that) to the correct directories and with the correct permissions may require root access.
Opening port 443 inbound at the firewall likely also requires root access.
Updating the web server's configuration to use SSL isn't as hard as you make it out to be - at least not for the Apache webserver. Once your configuration requires passing some of the requests through to helper/worker threads, and other fun stuff like orphaned software, then it can really take a while.
Forum-posted ideas are freely adoptable.
WhatIF Stories: Buy the Book
Discussion Thread
- Kristin Darken
-
Fate guard you and grant you a Light to brighten your Way.
- Kettlekorn
-
- null0trooper
-
Forum-posted ideas are freely adoptable.
WhatIF Stories: Buy the Book
Discussion Thread
- Kristin Darken
-
Fate guard you and grant you a Light to brighten your Way.
- XaltatunOfAcheron
-
Topic Author
Kristin Darken wrote: I think the key here is to remember that we aren't using a web hosting service. We're using a cloud server provider.
There may be some light. I've got family members that work in systems administration for major IT service companies. I showed the problem to one of them, and he said: "hm, we've got some people who work with Google cloud compute engine. That's their job. I'll ask one of them if they've got a step-by-step for converting a site from http to https."
We'll see if that bears usable fruit.
- Kristin Darken
-
And just a reminder for those thinking "I thought Kristin WAS the administrator responsible for this" ... need to remember that, for example, we bring in $300 per month in donations to keep the site functioning compared to the $3000-5000 in upkeep and costs that BigCloset operates on. We are hugely thankful to those who ARE donating... especially because that allows us to do so without the need for advertisements and what limited revenue we get from those (and we get to keep more of it because I don't have to file donations as income like I did ad revenue)... but even on slow months, what's necessary to keep things running falls more on contributed effort than paid worker.
I may be the admin here, but I'm plenty aware that my experience level is at that of a hobbyist... and that most of my 'hardcore' computer experience is woefully outdated (and targeted/specialized in areas other than IT admin).
Fate guard you and grant you a Light to brighten your Way.
- Malady
-
Firefox has FoxReplace that can do site specific text modding, but never used it much...
Firefox can also do personal css, I think?
- XaltatunOfAcheron
-
Topic Author
Malady wrote: I wonder if this could be fixed with a text replacer that mods the Wiki's "external link" class, since, at a glance, that seems to be the problem.
Firefox has FoxReplace that can do site specific text modding, but never used it much...
Firefox can also do personal css, I think?
This is intriguing. I didn't know that it had an "external link" class that could be changed on a per-wiki basis. Tell me more.
- Malady
-
XaltatunOfAcheron wrote:
Malady wrote: I wonder if this could be fixed with a text replacer that mods the Wiki's "external link" class, since, at a glance, that seems to be the problem.
Firefox has FoxReplace that can do site specific text modding, but never used it much...
Firefox can also do personal css, I think?
This is intriguing. I didn't know that it had an "external link" class that could be changed on a per-wiki basis. Tell me more.
And, as seen when you view-source a valid page, it's actually "external text"... Whoops.
FoxReplace ( Code: Github ) gets me most of the way there, I just need to make it replace my actual HTML tags, instead of just bare text...
Adding "crystalhall.wikia.com" makes it work on all of the Wiki, I just can't get it to change the tags, specifically... I could fork it and tweak, but have no add-on coding experience.
- XaltatunOfAcheron
-
Topic Author
Malady wrote:
XaltatunOfAcheron wrote:
Malady wrote: I wonder if this could be fixed with a text replacer that mods the Wiki's "external link" class, since, at a glance, that seems to be the problem.
Firefox has FoxReplace that can do site specific text modding, but never used it much...
Firefox can also do personal css, I think?
This is intriguing. I didn't know that it had an "external link" class that could be changed on a per-wiki basis. Tell me more.
And, as seen when you view-source a valid page, it's actually "external text"... Whoops.
FoxReplace ( Code: Github ) gets me most of the way there, I just need to make it replace my actual HTML tags, instead of just bare text...
Adding "crystalhall.wikia.com" makes it work on all of the Wiki, I just can't get it to change the tags, specifically... I could fork it and tweak, but have no add-on coding experience.
I don't know why you need to change the tags. The href= contains the URL. It appears that Fandom is simply deleting the "http:" part and leaving "//whateleyacademy.net/...." Then the browser takes its default when it doesn't see a scheme (which appears to be "https:") and away we go to "server not found".
So replacing "//whateleyacademy.net" with " whateleyacademy.net " ought to work.
Since I'm on Safari, I have to find a plugin that will do it for me; firefox plugins probably won't work well. Sigh.
- null0trooper
-
[
{
"uuid": "b58c22f6-8132-47fa-8909-81b999e1d6a6",
"pattern": {
"scheme": "*",
"host": [
"whateleyacademy.net"
],
"path": [
"*"
]
},
"action": "redirect",
"active": true,
"title": "Use%20port%2080%20for%20Crystal%20Hall",
"redirectUrl": "[protocol=http]",
"description": "Filter%20out%20SSL%20requests%20for%20a%20site%20that%20doesn't%20support%20them",
"paramsFilter": {
"values": [
"{href/https/http}"
]
},
"skipRedirectionFilter": true
}
]
Forum-posted ideas are freely adoptable.
WhatIF Stories: Buy the Book
Discussion Thread
- XaltatunOfAcheron
-
Topic Author
OOPS - I may have been hasty. I can't get to Muse-Of-Krews, and the page source looks like the same. What might have happened is that I've been going over the same 15 pages, so the browser might have gotten them from the cache.
I had some hopes....
- XaltatunOfAcheron
-
Topic Author
XaltatunOfAcheron wrote: It looks like Fandom backed the change out. I'm able to get to whateleyacademy.net from Fandom, and the page source looks like it's got the usual http:// prefix.
OOPS - I may have been hasty. I can't get to Muse-Of-Krews, and the page source looks like the same. What might have happened is that I've been going over the same 15 pages, so the browser might have gotten them from the cache.
I had some hopes....
Well, it's been working perfectly for the last couple of weeks, so I guess they did back the change out. This ticket can be closed.