Wiki best practices

Thenomain

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.

Tinuviel

@Thenomain Is there a method by which one can control wiki account creation through MU*-based SQL fuckery?

For example when a character is flagged approved, the account is created or somesuch?

Thenomain

@Tinuviel said in Wiki best practices:

@Thenomain Is there a method by which one can control wiki account creation through MU*-based SQL fuckery?

For example when a character is flagged approved, the account is created or somesuch?

Since the entirety of MediaWiki can be messed around with through SQL fuckery, yes. This is not knowing which encoding method MW uses for passwords, but there are a number of standards and most of them are built into mySQL. I'd imagine that MW uses whatever method that database handler uses.

Tinuviel

I know Evennia has a (I believe by default) wiki connection, alongside its web-based client. Perhaps digging into those configurations could be worth a look - assuming they resemble anything a sane (read: MU* coder) person could look at.

ixokai

@Thenomain said in Wiki best practices:

@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.

I could not disagree more. If it were a real password or an actual valuable resource, sure, but its not. Its a password that everyone who is approved has access to: its not really even a password. Its something which has no purpose but to make it so people can make accounts with some bit of information obtained in-game that establishes themselves therefore as a) not bots, b) not spammers.

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.

Oh, hell no. Asking for an email address is a nonstarter. There's too many people who will not give it-- and they shouldn't have to to play a freaking MUSH.

Dear lord you're making this complicated. It's a wiki for a MUSH. Worst case scenario someone creates a character, goes through the approval process for the diabolical purpose of err, vandalizing our wiki. At which point we shrug, ban them, and revert the changes.

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

How does that involve zero staff involvement? Quote the page: "and requires the approval of new accounts by a bureaucrat."

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.

How is this any better?

You're defending against some diabolical site admin attaching a snooper to a telnet session to see the super not even vaguely secret 'password' to create a website by... adding various levels of work for varying people for what reason again? What is the actual benefit to any of this complication?

Tinuviel

@ixokai This isn't an argument. Various people are offering advice and suggestions, as requested. If you have a problem with a suggestion, criticize constructively. Don't be a dick about it, this isn't the hog pit.

ixokai

@Tinuviel said in Wiki best practices:

@ixokai This isn't an argument. Various people are offering advice and suggestions, as requested. If you have a problem with a suggestion, criticize constructively. Don't be a dick about it, this isn't the hog pit.

I did.

Tinuviel

@ixokai Well you're acting like your way is the ONLY WAY EVER. Not taking into account the simple fact that some people like doing it differently. I would rather put in a little work for some added security, much like Theno. You don't want to do that. That's fine. You're coming across as if the very idea of someone thinking in a different way to you is blasphemous.

Just let people voice their points without jamming your fist in their mouth. It's not difficult.

ixokai

@Tinuviel said in Wiki best practices:

@ixokai Well you're acting like your way is the ONLY WAY EVER. Not taking into account the simple fact that some people like doing it differently. I would rather put in a little work for some added security, much like Theno. You don't want to do that. That's fine. You're coming across as if the very idea of someone thinking in a different way to you is blasphemous.

Just let people voice their points without jamming your fist in their mouth. It's not difficult.

No. @Thenomain made an absolute statement: Never Send Passwords Over Plain Text. This is usually a good rule, but: I think this is bad advice (especially considering you usually send your MUSH credentials via plain text) in this specific context, for the reasons stated. Then he said its better to use email address as a part of authentication: and I think that's also bad advice in a MUSH context for the reasons stated.

This isn't an 'effort vs security' balance, as its mostly just security theater.

Besides which, shut up and stop playing moderator. I don't care what you think. If I think @Thenomain is giving bad advice I'm gonna say why I think its bad advice. I am well aware this isn't Hog Pit, which is why I haven't said anything mean or insulting or demeaning about anyone. I expressed disagreement with someone's advice. Deal with it.

This will be my final response to this absurd meta-discussion of yours about the discussion.

Thenomain

Wow.

Sorry for intruding on this discussion. Theatre indeed.

Arkandel

MU* passwords to me fall into the same category as throwaway accounts in random web sites; i.e. I don't really care that much about how secure they are, especially since (of course) I never reuse them outside of MU* anyway. They contain no personal information.

Thenomain

@Arkandel

But sending passwords in the clear doesn't count as a best practice. It may be good enough for nonsense gaming, but that's a different answer in my book.

Tinuviel

This is all assuming this was a wiki for X reason. That's not how any of this works. We were asked for best practices in general. Just because Y is inconvenient doesn't mean that it is wrong. If you want to run anything at all, then following basic security procedures (don't store passwords as plaintext, don't allow anyone to access, et cetera) is fucking basic. If you want elementary shit then listen to @ixokai or @Roz. If you want actual basic internet security listen to @thenomain.

End of fucking conversation.

Roz

@Tinuviel I wasn't actually responding about general best practices, though. The question was about a MU* wiki with a spambot problem, so my answer was specifically about that. You snarked at @ixokai about acting like his way was the "only way ever" but you have been equally snarky throughout this thread for no particular reason I can identify.

Sunny

@Roz

Projection.

Thenomain

@Roz

Tho we've gone from answering the original question directly (which I did try to do!) to theory, and when you get a bunch of people who are prone to disagree already now talking about theory then yeah, I'm not surprised this happened. Sometimes having a meta-discussion is needed to clarify which interpretation any one given person is having, because topic drift is a real thing. (I know you weren't talking about it, Roz, it just came to mind for what I see what happened.)

Also, there are very good extensions to stop spambots. There aren't very good methods to create a secure link between a Mu* account and a MediaWiki account. I sincerely do hope the two I linked to help with both.

surreality

In fairness, the suggestion I have for someone to be able to common sense fix the problem the current mediawiki install has on digital ocean is not a best practice.

I am reasonably sure there's a more secure way to do it than the one I laid out through some back end, and the one provided does absolutely have risks (and big ones).

For someone without heavy duty SQL/mediawiki/server experience, however, it works and will fix the problem without incident most of the time. That describes me, really. I only know the fix because I ran into the same problem, and after digging around about how to go about it, that was the only answer I found.

At some point, you have to do what works and hope for the best, especially when the argument about how to get something done takes up more time than researching how and getting it done.