You are here
Tango - Fri, 2024/05/03 - 17:17
Every time I start to tinker with the security settings on this thing, I break it. So I've rebuilt my appliance (again) and rebuilt my wiki.. and manually migrated the content (since I couldn't get the migration process to work). So in an effort to not break this instance, I'm asking.
I use VisualEditor and need to not break it. Based on what I've read, this means that the entire wiki basically has to be unsecured for this to work. My goal is to secure the wiki - login required to view pages, visualeditor still functional. Running 18.0
So how do I secure it without breaking it?
TIA
Forum:
Could you please give some more specifics on the issue(s)?
FYI we have ~100 different appliances so beyond general Linux stuff, my knowledge tends to be broad and general, rather than deep and specific. While I know bit about Mediawiki, it's been nearly 10 years since I was a regular Mediawiki user/maintainer and I'm certainly no expert. So you likely already know more about your problem than me.
OTOH I'm intimately familiar with TurnKey and have lots of webserver knowledge and a bit of PHP knowledge too. I have also done some maintenance of our Mediawiki appliance. Plus I like to think that I'm a pretty good problem solver. So whilst you've given some details, the clearer and more specific you can be the better. Ideally it'd be good if I can reproduce the issue locally. So here's some questions for you. Hopefully they don't make me sound too stupid! :)
Also something of an aside, you mention that "the migration process" didn't work. I assume that you are referring to using TKLBAM but again it'd be useful to understand exactly what you did and how it didn't work. FWIW you can break the restore up into separate steps and just restore certain components. Often issues occur when migrating data from old servers where some specific settings are incompatible, so doing it stages or only restoring specific components (e.g. your DB and some specific directories).
Anyway, that's secondary at the moment, but I'd love to know more about the issues you encountered as perhaps I can document things things better and/or clarify the notes on the TKLBAM overview doc page?
More information
HI JD:
Regarding my experience with the migration failure, I was attempting to do a manual migration - TLKBAM looked like it requires an AWS instance to work and I didn't want to mess with that. /shrug Couldn't get it to work.
Prior to migration though I was trying to enable 'sign on needed to view pages' and 'sign on needed to edit pages' --- changing the permissions at all seemed to break visual editor. Granted, I was on 17.1 build and am now on the 18.0 build. So I rebuilt the entire wiki and migrated my data over manually (page by page copy and paste). So I'm trying really hard to not break this version - but I would like to be able to enable sign on for viewing and editing.... without breaking visual editor.
For this reason I am seeking further specific information before I begin altering code and/or permissions as I really don't want to break it again.
Thanks for the responsiveness!
Following up on this - seems its not possible :(
I'm just following up on your question/problem.
After doing a bit of testing myself and a bit of research, unfortunately it seems that as you discovered, it's currently not possible to have both VisualEditor enabled AND login required to view your wiki. :(
There is something of a workaround possible by enabling Apache (webserver) "Basic Authentication". But strictly speaking, it's not really secure, as unauthenticated users can workaround it relatively easily.
For more info/detail, please see this Mediawiki Support Desk post/thread.
I haven't tested so I can't be 100% sure, but I think that it may be possible to have VisualEditor enabled and limit read access to specific IP addresses (via firewall). But even if that works as I imagine it would, that would only be practical if all users you want to allow read access are behind static IPs and no one ever needs to access your wiki when away from the trusted IP(s).
Some more info... And a suggestion (at the end)
I just wanted to circle back to this.
The first part (directly below) is some context re the Mediawiki change in behavior and speculation on why. The second (TL;DR - below the second dividing line) is perhaps a way for you to achieve your aims?
On face value th new behavior/limitation is a regression and ultimately I guess it is. But I'm 99% sure that there is reasonable context for the change and I suspect they will be provide your desired behavior, but not sure when that might be. It will rely on community interest and someone to develop it. I'm not 100% sure why they chose the path they did or exactly how the new visualeditor works, but I could speculate...
The previous WYSIWYG editor (what you see is what you get - i.e. a visual rather than wiki/html/etc code editor) was provided by an extremely popular javascript implementation, called CKEditor. It's open source but in more recent versions the free, open source version is missing many of the cool features and isn't anywhere as feature-full as commercially licensed paid version. So because of licensing, the choice was a limited editor, or something else.
Rather than move to an alternate javascript front end implementation similar to CKEditor, they did what many new projects do these days, and moved to editor provided by a separate service, integrated with the main app in your browser (so it's transparent). For security, this separate service and the main web app need to be closely locked together - so no malicious actor could provide their own editor. That is relatively easy to implement, but locked down user accounts complicate it.
Mediawiki's main backer and developer is Wikipedia. As you'd know, "readable to everyone" is a feature. So the config you want is not a core requirement for the project that is paying for Mediawiki development. As I say, your desire is technically possible but someone needs to develop it - or pay someone to.
TL;DR IMO your best bet is to explore alternate wiki software. The significant downside is that you'll need to migrate your existing content, which will likely be a PITA.
Regardless, we've got a few other wiki appliances that might be worth a look:
A newer, popular and quite flexible one is BookStack. TBH I'm not sure about WYSIWYG editor, but I'd be surprised if it didn't. The only possible downside is that AFAIK it is really targeted at personal and small project usage, rather than business (which I gather you're after?). Check it out.
Two other ones, not as popular, are DokuWiki and Foswiki. I'm not 100% sure about editors in them either, but probably worth a look too.
Anyway, I hope my waffle is of some value?!
If you do look at the other ones we've got, I'd be really interested in your thoughts and feedback.
Add new comment