From szybalski at gmail.com Sun Apr 19 00:49:45 2020 From: szybalski at gmail.com (Lukasz Szybalski) Date: Sat, 18 Apr 2020 23:49:45 -0500 Subject: [moin-user] Number 1 Next Feature of MoinMoin - Anti-spam Message-ID: Hello I wanted to revive the discussion about Number 1 feature that moinmoin needs, which is anti-spam. All admins as yourself and me are forced to lock down our wiki's because we cannot manage 1000s of fake users creations, and fake pages. I realized that my website as well as others are suffering from growth, because users are not able to register. I wanted to get your ideas on how to accomplish this, feel free to sort them in "easiest" to build/deploy now order. a) "one command" to enable "google re-captcha" ( https://developers.google.com/recaptcha/docs/v3). (As much as we don't want to use commercial versions, and would love to see our own build, I think its time we enable something that is "crowed sources".) b) Register and Authenticate with google. c) "Service and one config line change to enable" similar to https://wordpress.org/plugins/akismet/ d) ? (Always evolving?) Again, my hope is to free us and revive the moinmoin to what it should be. A Growing community open to anyone, except spammers. 1. I would hope that the first site to use this would be: http://moinmo.in/ 2. I hope we have some volunteers that can help out. 3. Would it be possible for Roger or Thomas to apply for "Google summer of code" sponsorship and improve on this #1 needed feature next summer. 4. Start a bounty. I'll pitch in. Thank you Lucas -- http://lucasmanual.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at boddie.org.uk Sun Apr 19 09:41:15 2020 From: paul at boddie.org.uk (Paul Boddie) Date: Sun, 19 Apr 2020 15:41:15 +0200 Subject: [moin-user] Number 1 Next Feature of MoinMoin - Anti-spam In-Reply-To: References: Message-ID: <2326409.f8DLr4N8KE@jeremy> On Saturday 18. April 2020 23.49.45 Lukasz Szybalski wrote: > Hello > I wanted to revive the discussion about Number 1 feature that moinmoin > needs, which is anti-spam. All admins as yourself and me are forced to lock > down our wiki's because we cannot manage 1000s of fake users creations, and > fake pages. I realized that my website as well as others are suffering from > growth, because users are not able to register. I definitely agree that the registration workflow is not optimal. Although as much as e-mail is maligned these days, having people mail wiki administrators (perhaps via mailing lists) has been a mostly acceptable workaround, but it is cumbersome and can be subverted. (It also has to be said that MediaWiki instances are often protected similarly. I have seen recaptcha widgets on some MediaWiki instances, but many sites have presumably decided that it doesn't work effectively enough.) > I wanted to get your ideas on how to accomplish this, feel free to sort > them in "easiest" to build/deploy now order. > > a) "one command" to enable "google re-captcha" ( > https://developers.google.com/recaptcha/docs/v3). (As much as we don't > want to use commercial versions, and would love to see our own build, I > think its time we enable something that is "crowed sources".) Here, I think that anything that people might believe to be helpful is worth trying, as long as they don't think it alone solves all their problems. Some of the more successful anti-spam systems involve several different measures and probably have a significant degree of manual intervention. As an example of just one possible measure, I made an extension for Moin that timed the delay between page loading and saving. This is just one of many measures employed by things like Wordpress. I don't remember making it available, perhaps because I wasn't exactly motivated to do so given the rather subdued atmosphere around Moin development. > b) Register and Authenticate with google. Again, this could work, but given how many GMail accounts are compromised regularly, it has its limitations. I don't know what the situation is with authentication APIs these days. A long time ago, I fixed the OpenID support in Moin, but I imagine that the big cloud companies dropped support for such interoperability technologies in order to make their own "power plays". Of course, being authenticated is only one step along the path towards maintaining the integrity of a wiki. I remember OpenID support on some python.org resources being limited to major service providers because of a misunderstanding that this somehow made the credentials substantially more valuable. In fact, getting an identity from somewhere is arguably the easiest problem to solve (both for spammers and for those trying to identify visitors). > c) "Service and one config line change to enable" similar to > https://wordpress.org/plugins/akismet/ My understanding is that Akismet is precisely the kind of bundle of measures that I mentioned above. So this would be a good idea, but I don't know how much work it would be. > d) ? (Always evolving?) We haven't seen much development activity on Moin for a long time. I don't know what the core developers have been doing, but community involvement has evaporated over the years. > Again, my hope is to free us and revive the moinmoin to what it should be. > A Growing community open to anyone, except spammers. > > 1. I would hope that the first site to use this would be: http://moinmo.in/ > 2. I hope we have some volunteers that can help out. > 3. Would it be possible for Roger or Thomas to apply for "Google summer of > code" sponsorship and improve on this #1 needed feature next summer. > 4. Start a bounty. I'll pitch in. Being in the fortunate position of still being employed at this moment, I would also be prepared to help pay someone to work on these things. Despite various organisations making good use of Moin and very rarely supporting its developers, it perhaps falls to us to try and set a good example. (Now that organisations can't spend most of their money on pizza and beer for hackathons because paying Free Software developers is taboo - "because companies" - maybe some funds will make their way to those people who were always developing tools for distributed working.) I will now add my own remarks about strategies for dealing with spamming. Firstly, I will probably be repeating myself by indicating that I don't agree with the stubbornly persistent notion that anyone should be able to edit a wiki and that the process of doing so should be as absolutely easy as possible. In this day and age, I doubt that there are many sites that would benefit from such an approach at all, but unfortunately people will undoubtedly be perpetuating this mythical notion of wikis based on what Ward Cunningham thought back in the day. With the view that editing should be authenticated and access suitably controlled, I wonder if we shouldn't be making more use of trust networks. I was going to suggest that client certificates would be interesting to get past the authentication stage, but even in this era of Let's Encrypt and ubiquitous server certificates, it seems that client certificates have been forgotten. Maybe there are projects that offer solutions, although the one I immediately thought of - http://web.monkeysphere.info/ - does not seem to be obviously helpful for this particular situation. What then needs to be considered is how a new user is to be trusted. In the e- mail verification approach, this is all decided using classic social interactions: have we heard of this person before, what have they done that we recognise, and can we trust them to do the right thing? A "web of trust" approach could help with that, perhaps suggesting a role for technologies like OpenPGP (which the likes of Debian use to an extent). (There are also questions about how damage can be reverted if someone proves not to be trustworthy, but this is a completely new and substantial topic.) Hopefully, some other people might be able to offer advice and opinions. Again, I would be happy to support anyone working in a concrete way towards sustainable solutions. Paul P.S. I already noted that my own use of Moin has declined due to it being a burden to run, leading me to publish Moin format content using a set of tools I developed: http://projects.boddie.org.uk/MoinLight/ This isn't a solution for collaborative sites all by itself, however. From lievendp at gmail.com Thu Apr 23 09:56:00 2020 From: lievendp at gmail.com (Lieven De Puysseleir) Date: Thu, 23 Apr 2020 15:56:00 +0200 Subject: [moin-user] givenauth and xmlrpc authentication Message-ID: Dear List, What is the most preferred way to have xmlrpc facility together with an apache basic auth in front? Or even Apache with kerberos? The main thing here as I understand it, is that apache will use the REMOTE_USER variable which can then be used by moinmoin (version 1.9.10 from suse package) and givenauth to authenticate a user. This works fine an sich. It also works using apache kerberos authentication module. With the standard moinauth, I'm able to connect and putpage with xmlrpc, this works fine using the multicall and authtoken. However, the combination of wanting to use xmlrpc together with REMORE_USER seems bizarre because apache cannot use REMOTE_USER for xmlrpc authentication? So when using apache basic authentication I manage to have it kind of working if I put the username and password in the url with xmlrpc2 and then extra do add the authtoken in the multicall as well as documented. Is there an existing solution or workaround for this? Something that allows givenauth to work together with xmlrpc authentication? I cannot seem to find it in the documentation. Thanks and kind regards! -- Lieven -------------- next part -------------- An HTML attachment was scrubbed... URL: