Wiki best practices



  • Hey gang, I noticed last night that my wiki has been noticed by bots. Before the few become many, I was hoping someone with a few more levels of wiki-fu could clue me into some best practices for heading this stuff off at the pass. I've looked at some of the help pages and, as a neophyte, they didn't really help.

    Also any other good things to do with a fresh install would be groovy. I'm using Mediawiki if that matters.



  • Firstly, make it locked to editing except for account users. Unless you've already done that!


  • Pitcrew

    I use the ConfirmEdit CAPTCHA extension to control user registration instead of leaving it open. I specifically use the QuestyCaptcha option, which lets you define a question and answer. I do something that's pretty straightforward based on the theme or the game (and sometimes have a +wiki command or something similar that spits out the answer on-game). (Like, for the Arx unofficial player wiki, I made it something like "Who's the head GM on game?")



  • Or, as an alternative to Roz's suggestion, have account creation be manual only. That seems to be a popular choice.


  • Pitcrew

    @Tinuviel Yeah, but a much more annoying and ongoing hassle for the admins. CAPTCHA you set up once and forget about it.



  • @Roz Well, it's not a hassle if you want to prevent non-members of whatever group from editing. Which is the point.


  • Coder

    Yeah, on mediawiki sites I always do manual creation of accounts.

    That said, its primarily because I've never heard of QuestyCaptcha before. I'd use that and have a command in game that's available only once approved, you type +wiki/password and get a password you enter into there. (This is basically what I do for wikidot wiki's)


  • Pitcrew

    @Tinuviel I get that that's the point? Both of the solutions accomplish the same thing. I'm saying that one of them is a one-time setup and one of them requires repeated admin work forever.



  • Okay, next question. When I installed it, it didn't make my account an admin. Now I can't promote anyone to admin powers. FML. is there a way to do this in kitty?


  • Pitcrew

    @SG Do you mean you installed the ConfirmEdit extension? This shouldn't affect your wiki account permissions either way -- your user permissions are set by the various Users and Rights Special Pages. Your wiki has to have an admin account that would have been defined during the actual MW install process.

    (Also, I have no idea what "is there a way to do this in kitty?" means. I'm sorry.)



  • @SG Oh crap. OK. Is this on digitalocean? Because their latest install does this. And it is a pain in the ass.

    What you are going to need to do:

    ssh into your account and edit your local settings file (LocalSettings.php)

    You are going to want to do something that you never want to ever, ever, EVER do under any other circumstances.

    Add this line:

    $wgGroupPermissions['user']['userrights'] = true;

    Save your work to LocalSettings.php and go back to your wiki immediately. You will now be able to change your account to the proper administrator/bureaucrat options.

    THE MOMENT YOU DO SO, GO BACK TO LOCALSETTINGS.PHP ON YOUR SERVER AND DELETE THAT LINE OF CODE YOU ADDED ABOVE.

    Save LocalSettings.php again (without that line in it), and you should be fixed.

    Is this a crappy workaround? Ayep. Still have had to do it twice now. Which is a giant pain in the arse, but it works.

    I don't know kitty, either, to give you the specifics you need for the editing, but you'd do those edits however you've been editing your LocalSettings.php file any other time.


  • Coder

    Digital ocean tells you the setup for your wiki when your first log in to the shell upon creation. And I assume @SG means KiTTY which is just an ssh client for windows.



  • @Glitch It should, yeah -- but there's something borked in their one click droplet the last few times I've used it -- that doesn't actually set the permissions for administrator/etc. on that account, even though you go through the steps to set it up. I had to dig up the workaround above a few times to adjust for that. :/

    There's another line I needed to make sure to include also that normally should be there on creation by default, but I cannot for the life of me recall which/what it is/was.



  • @Roz No. One allows anyone to sign up and edit whatever. The other requires that they be a person known to the admin. It might be "more work" but it serves a purpose that captcha doesn't fill.


  • Pitcrew

    @Tinuviel said in Wiki best practices:

    @Roz No. One allows anyone to sign up and edit whatever. The other requires that they be a person known to the admin. It might be "more work" but it serves a purpose that captcha doesn't fill.

    It allows anyone on your game to sign up, yeah. (Hence using a simple question CAPTCHA that requires familiarity with the game/being on the game to hit a command.) The OP's problem is combatting bots, not combatting malicious players.



  • @surreality Yeah, that's exactly what happened. Looks like it worked : ) Thanks!



  • @Roz Sure, they're not having a problem with malicious people. But this is still about security. Solve all the problems you can, not just one. Captcha is fine, if you don't mind anyone that can look through a wiki to get information (or a game, or whatever source you choose). And if it's game specific, you'd better remember to keep the captcha question and answer up to date. Like how wikis are always up to date.

    Locking account creation out is a set it and forget it option, that works every time.


  • Pitcrew

    @Tinuviel said in Wiki best practices:

    @Roz Sure, they're not having a problem with malicious people. But this is still about security. Solve all the problems you can, not just one. Captcha is fine, if you don't mind anyone that can look through a wiki to get information (or a game, or whatever source you choose). And if it's game specific, you'd better remember to keep the captcha question and answer up to date. Like how wikis are always up to date.

    You pick a question and answer that's easy/fundamental to the game, not something that changes.

    Locking account creation out is a set it and forget it option, that works every time.

    It's -- literally the opposite of a set it and forget it option. Because you set it and then have to create every new account manually. So you set it and -- do it repeatedly every time it needs doing.

    If you never have an issue with malicious players trying to wreck stuff, you just made a bunch of continual work for yourself for no reason in the name of "solving all the problems you can."



  • @Roz said in Wiki best practices:

    @Tinuviel said in Wiki best practices:

    @Roz Sure, they're not having a problem with malicious people. But this is still about security. Solve all the problems you can, not just one. Captcha is fine, if you don't mind anyone that can look through a wiki to get information (or a game, or whatever source you choose). And if it's game specific, you'd better remember to keep the captcha question and answer up to date. Like how wikis are always up to date.

    You pick a question and answer that's easy/fundamental to the game, not something that changes.

    If it's easy or fundamental, then it's useless as a security measure.

    Locking account creation out is a set it and forget it option, that works every time.

    It's -- literally the opposite of a set it and forget it option. Because you set it and then have to create every new account manually. So you set it and -- do it repeatedly every time it needs doing.

    You need to create accounts. Yeah. You don't need to constantly make sure that your security is up to date. One it is set, you don't need to worry about it.

    If you never have an issue with malicious players trying to wreck stuff, you just made a bunch of continual work for yourself for no reason in the name of "solving all the problems you can."

    If you want to prevent all but a select group from accessing something, you give only them access. You don't let people try and answer a riddle to get in, you just lock the door.

    We were asked for best practices. Not what's easy to do.


  • Coder

    @Tinuviel said in Wiki best practices:

    @Roz said in Wiki best practices:

    @Tinuviel said in Wiki best practices:

    @Roz Sure, they're not having a problem with malicious people. But this is still about security. Solve all the problems you can, not just one. Captcha is fine, if you don't mind anyone that can look through a wiki to get information (or a game, or whatever source you choose). And if it's game specific, you'd better remember to keep the captcha question and answer up to date. Like how wikis are always up to date.

    You pick a question and answer that's easy/fundamental to the game, not something that changes.

    If it's easy or fundamental, then it's useless as a security measure.

    ... nonsense.

    Type '+wiki/password' in game. Receive the word: 'transgoggle'.

    Easy. And staff doesn't have to do anything ever again and no bot or spammer will ever get it.

    Locking account creation out is a set it and forget it option, that works every time.

    It's -- literally the opposite of a set it and forget it option. Because you set it and then have to create every new account manually. So you set it and -- do it repeatedly every time it needs doing.

    You need to create accounts. Yeah. You don't need to constantly make sure that your security is up to date. One it is set, you don't need to worry about it.

    And you need to actually go through and make all the accounts, either dealing with players not giving you a name/password that works, or telling them a temporary password, or having to ask for an email to send them a randomly generated temporary password... All of this is work.

    @Roz's solution is no work. And damn near perfect security: the only issue is anytime you ban a player, you want to change the password. Easy to do. And how often do you ban players? On Marvel:1963 we've banned ... four. And changed the password each time (we actually change the password as a practice before we hit the ban button).

    We were asked for best practices. Not what's easy to do.

    Yeah, and you aren't giving best practices.


  • Coder

    @ixokai said in Wiki best practices:

    Type '+wiki/password' in game. Receive the word: 'transgoggle'.
    Easy. And staff doesn't have to do anything ever again and no bot or spammer will ever get it.

    Sending password over clear-text is never, ever a good idea.

    edit: I should amend this, knowing that I took one bit of information from a wider discussion and jumped on it. I stand by this statement: Don't send passwords in the clear.

    That's not to say that this system can't still be easy, but it should require a two-factor system such as email. Register and verify an email, and then when someone types '+wiki/password' it starts the process via the registered address. It still doesn't involve any third party, which is easier and is good.

    There is also a fantastic wiki plugin called Extension:ConfirmAccount which also involves zero staff involvement.

    Mind you, these still involve work and our hobby puts a lot of stress on the overhead of game creation to begin with. Until someone creates this for public consumption, it's more something that might be done sometime. For this reason I prefer Extension:InviteSignup, as while yes it involves staff it's quite minimal, can be handled by anyone with wiki-staff, and will give your coder time to come up with something better.


Log in to reply
 

Looks like your connection to MU Soapbox was lost, please wait while we try to reconnect.