From tw at waldmann-edv.de Tue Sep 3 05:04:28 2013 From: tw at waldmann-edv.de (Thomas Waldmann) Date: Tue, 03 Sep 2013 11:04:28 +0200 Subject: [Moin-user] Spam on Moin wikis and anti-spam best practices In-Reply-To: <201308292337.07458.paul@boddie.org.uk> References: <201308292337.07458.paul@boddie.org.uk> Message-ID: <5225A61C.7050903@waldmann-edv.de> > perhaps we need safer defaults I don't think we should change defaults within a stable release series. But we can change how example configs look like and document stuff better. > Really control registration: for extra control over registration, perhaps use > the http://www.moinmo.in/MoinMoinPatch/VerifyAccountCreationByEmail patch to > require e-mail verification of account registration. I wouldn't recommend this patch until someone cleans it up (see my comments there), does more testing and reviews the code again. > Does anyone have any opinions about the above? Good writeup, should be supplemented with a modified default wiki/farm config. One can add to regularly review logs, esp. after spam gets in. So one can sometimes identify static IP addrs only used for spamming (put them in moin's hosts_deny or handle via web server) and also textchas that have been broken and should be replaced. From steve at einval.com Tue Sep 3 08:41:16 2013 From: steve at einval.com (Steve McIntyre) Date: Tue, 3 Sep 2013 13:41:16 +0100 Subject: [Moin-user] Spam on Moin wikis and anti-spam best practices In-Reply-To: <5225A61C.7050903@waldmann-edv.de> References: <201308292337.07458.paul@boddie.org.uk> <5225A61C.7050903@waldmann-edv.de> Message-ID: <20130903124055.GA706@einval.com> On Tue, Sep 03, 2013 at 11:04:28AM +0200, Thomas Waldmann wrote: >> perhaps we need safer defaults > >I don't think we should change defaults within a stable release series. > >But we can change how example configs look like and document stuff better. > >> Really control registration: for extra control over registration, perhaps use >> the http://www.moinmo.in/MoinMoinPatch/VerifyAccountCreationByEmail patch to >> require e-mail verification of account registration. > >I wouldn't recommend this patch until someone cleans it up (see my >comments there), does more testing and reviews the code again. Ah, bugger. Sorry, I hadn't seen the comments there. I'm subscribed to the page, but it looks like maybe my spam filter ate it or something. I'm in the middle of cleaning up and re-targetting my patches against 1.9.7 right now anyway. I'll update the page shortly. >> Does anyone have any opinions about the above? > >Good writeup, should be supplemented with a modified default wiki/farm >config. > >One can add to regularly review logs, esp. after spam gets in. So one >can sometimes identify static IP addrs only used for spamming (put them >in moin's hosts_deny or handle via web server) and also textchas that >have been broken and should be replaced. I've also added support for calling out to an external program at account creation time to see if a new account should be created, based on email/IP/account name. I've got quite a few extra scripts written locally to help with monitoring account signups and managing the blacklists too. More helpful things here would include: * better support for network addressing for blacklisting (something that understands CIDR rather than just .startswith) * support for moderation - new account holder should need to have their first few edits approved by existing users -- Steve McIntyre, Cambridge, UK. steve at einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering" From paul at boddie.org.uk Tue Sep 3 12:03:57 2013 From: paul at boddie.org.uk (Paul Boddie) Date: Tue, 3 Sep 2013 18:03:57 +0200 Subject: [Moin-user] Spam on Moin wikis and anti-spam best practices In-Reply-To: <20130903124055.GA706@einval.com> References: <201308292337.07458.paul@boddie.org.uk> <5225A61C.7050903@waldmann-edv.de> <20130903124055.GA706@einval.com> Message-ID: <201309031803.57794.paul@boddie.org.uk> On Tuesday 3. September 2013 14.41.16 Steve McIntyre wrote: > On Tue, Sep 03, 2013 at 11:04:28AM +0200, Thomas Waldmann wrote: > >> perhaps we need safer defaults > > > >I don't think we should change defaults within a stable release series. > > > >But we can change how example configs look like and document stuff better. Actually, this is what I was really suggesting. Although I think that Moin should be more secure "out of the box", it is impossible to deliver something acceptable for every audience. One of my aims with moinsetup (http://moinmo.in/ScriptMarket/moinsetup) is to be able to help people configure Moin for different kinds of audience. People should be in the habit of reviewing their configuration before exposing their site in whichever environment they have chosen. > >> Really control registration: for extra control over registration, > >> perhaps use the > >> http://www.moinmo.in/MoinMoinPatch/VerifyAccountCreationByEmail patch > >> to require e-mail verification of account registration. > > > >I wouldn't recommend this patch until someone cleans it up (see my > >comments there), does more testing and reviews the code again. > > Ah, bugger. Sorry, I hadn't seen the comments there. I'm subscribed to > the page, but it looks like maybe my spam filter ate it or > something. > > I'm in the middle of cleaning up and re-targetting my patches against > 1.9.7 right now anyway. I'll update the page shortly. As another layer of defence, I think that this extension would be a valuable addition to Moin. > >> Does anyone have any opinions about the above? > > > >Good writeup, should be supplemented with a modified default wiki/farm > >config. I may add this and put the writeup on the Moin Wiki. > >One can add to regularly review logs, esp. after spam gets in. So one > >can sometimes identify static IP addrs only used for spamming (put them > >in moin's hosts_deny or handle via web server) and also textchas that > >have been broken and should be replaced. > > I've also added support for calling out to an external program at > account creation time to see if a new account should be created, based > on email/IP/account name. I've got quite a few extra scripts written > locally to help with monitoring account signups and managing the > blacklists too. > > More helpful things here would include: > > * better support for network addressing for blacklisting (something > that understands CIDR rather than just .startswith) > > * support for moderation - new account holder should need to have > their first few edits approved by existing users There are tricks that other systems like WordPress (and its plugins) use to detect and filter out spam. I have indicated an interest to look into this, but all this stuff takes time, and I don't currently feel that I am in a position to be spending my time on developing such things. Still, increased adoption of the tools we do have available would probably help many people, in my opinion. Paul From frank4sam at gmail.com Thu Sep 12 03:52:34 2013 From: frank4sam at gmail.com (Sam Franklin) Date: Thu, 12 Sep 2013 13:22:34 +0530 Subject: [Moin-user] Need help with MoinMoin implementation Message-ID: Dear MoinMoin Team, New to MoinMoin need help with implementation, could you kindly recommend the right forum on support with implementation. Happened to have MoinMoin installed on Windows 2008 R2 Server, with the following binaries: Installed Binaries: ? Python - v2.6.6 ? Moin - v1.9.7 ? Httpd - v2.2.25 ? Python-ldap - v2.4.13 Having challenges in getting the LDAP integrated, any help would be appreciated. Best Regards, Sam -------------- next part -------------- An HTML attachment was scrubbed... URL: From harikripas at gmail.com Thu Sep 12 03:57:02 2013 From: harikripas at gmail.com (hari k) Date: Thu, 12 Sep 2013 15:57:02 +0800 Subject: [Moin-user] Need help with MoinMoin implementation In-Reply-To: References: Message-ID: Dear Sam , I have documented my setup here for linux : http://adminlogs.info/2013/04/28/how-to-login-moin-moin-using-ldap-credentials/ Hope that it will be helpful for you ! On Thu, Sep 12, 2013 at 3:52 PM, Sam Franklin wrote: > Dear MoinMoin Team, > > New to MoinMoin need help with implementation, could you kindly > recommend the right forum on support with implementation. Happened to have > MoinMoin installed on Windows 2008 R2 Server, with the following binaries: > > > Installed Binaries: > > > > ? Python - v2.6.6 > > ? Moin - v1.9.7 > > ? Httpd - v2.2.25 > > ? Python-ldap - v2.4.13 > > > > Having challenges in getting the LDAP integrated, any help would be > appreciated. > > > > Best Regards, > > Sam > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. Consolidate legacy IT systems to a single system of record for IT > 2. Standardize and globalize service processes across IT > 3. Implement zero-touch automation to replace manual, redundant tasks > http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > > -- Thanks & Regards, -------------- Hari.K -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.colmer at linaro.org Tue Sep 24 11:44:05 2013 From: philip.colmer at linaro.org (Philip Colmer) Date: Tue, 24 Sep 2013 16:44:05 +0100 Subject: [Moin-user] Suggestions sought to how best to implement this request ... Message-ID: Sorry that I couldn't come up with a better subject line ... I've been asked to migrate http://www.linaro.org/linux-on-arm/meet-the-team onto our internal MoinMoin wiki. The content from that page comes from the CMS that sites behind www.linaro.org and I am *not* going to be migrating that. Instead, my intention is to use the corporate LDAP directory to store the data and use some Python code to pull the data back from LDAP. I am, however, hitting some mental stumbling blocks and I'd welcome thoughts or comments on these: - The way that the lists are arranged into three columns seems to be some CSS voodoo that I'm trying to unpick. I'm not sure how to mimic that in MoinMoin since calling CSS directly is tricky ... - Clicking on an individual (e.g. http://www.linaro.org/linux-on-arm/meet-the-team/philip-colmer/) results in more "normal" layout although, again, the HTML seems to have some "interesting" CSS references but I might be able to ignore more of that and use a table instead to try to get to a similar look. My thinking here is that a script running directly on the server would run regularly and build static wiki pages based off LDAP data. For the person's photo, my research into MoinMoin seems to suggest that an attachment would seem to be the best solution as I can transfer the JPEG data from the LDAP server and store it inside the attachments directory for that page. Is there an API for storing attachments or should I just write directly to the page's directory structure? - Similarly with the lists of people in a group (e.g. http://www.linaro.org/linux-on-arm/meet-the-team/office-of-the-coo), my intention is to build a wiki page for each group. However, if I've gone for the aforementioned approach of storing the images as an attachment for an individual page, can I reference that from another page? If not, I guess the better solution would be to store all of the staff images in a central directory and then consistently link to them as external images. Any other suggestions or thoughts occur to you? Thanks for any input that anyone can provide on this. Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at boddie.org.uk Tue Sep 24 16:38:05 2013 From: paul at boddie.org.uk (Paul Boddie) Date: Tue, 24 Sep 2013 22:38:05 +0200 Subject: [Moin-user] Suggestions sought to how best to implement this request ... In-Reply-To: References: Message-ID: <201309242238.06540.paul@boddie.org.uk> On Tuesday 24. September 2013 17.44.05 Philip Colmer wrote: > Sorry that I couldn't come up with a better subject line ... I've been > asked to migrate > > http://www.linaro.org/linux-on-arm/meet-the-team > > onto our internal MoinMoin wiki. The content from that page comes from the > CMS that sites behind www.linaro.org and I am *not* going to be migrating > that. Instead, my intention is to use the corporate LDAP directory to store > the data and use some Python code to pull the data back from LDAP. > > I am, however, hitting some mental stumbling blocks and I'd welcome > thoughts or comments on these: > > - The way that the lists are arranged into three columns seems to be > some CSS voodoo that I'm trying to unpick. I'm not sure how to mimic > that in MoinMoin since calling CSS directly is tricky ... Without actually looking at the CSS, my way of reproducing this would be to use "float: left" on the lists. That might actually do enough, but usage of "clear: left" and "clear: right" would also help. If you were doing this in the source of a normal wiki page, you'd be able to attach CSS to tables using tablestyle... || This table floats left! || || Some content in the page. || ...but putting lists inside table cells would be awkward: the standard Moin tables allow only single line cells/rows, and I think you'd have to use the MiniPage macro which doesn't really lend itself to readability: http://moinmo.in/MacroMarket/MiniPage You could use my ImprovedTableParser to put lists inside the extended tables it supports, since it does allow cells to be defined across multiple lines: http://moinmo.in/ParserMarket/ImprovedTableParser I imagine, however, that since you're using content dynamically fetched from LDAP, you're probably just going to write your own Moin extension, perhaps a macro that you then insert into a page like this... <> ...and then you will have the freedom to generate whatever HTML you like for the retrieved content. In your macro, you'd probably use the formatter API to make the lists like this: def execute(macro, args): fmt = macro.formatter ... output = []; append = output.append ... append(fmt.bullet_list(on=1, attr={"class" : "stafflist"})) ... append(fmt.listitem(on=1)) ... append(fmt.listitem(on=0)) ... append(fmt.bullet_list(on=0)) ... return u"".join(output) If you can re-use the CSS from before, you could name the CSS class for each list as above. Otherwise, I think you can define a style attribute. If not, I probably have a patch against Moin that lets you define one. ;-) See the MacroMarket for examples of macros: http://moinmo.in/MacroMarket There is some sort of guide to writing macros, but just looking at existing simple ones in the MoinMoin.macro package can be just as informative: http://moinmo.in/MoinDev/CreatingMacros > - Clicking on an individual (e.g. > http://www.linaro.org/linux-on-arm/meet-the-team/philip-colmer/) results I thought I recognised your name from the Acorn era! :-) > in more "normal" layout although, again, the HTML seems to have some > "interesting" CSS references but I might be able to ignore more of that > and use a table instead to try to get to a similar look. My thinking here > is that a script running directly on the server would run regularly and > build static wiki pages based off LDAP data. For the person's photo, my > research into MoinMoin seems to suggest that an attachment would seem to > be the best solution as I can transfer the JPEG data from the LDAP server > and store it inside the attachments directory for that page. Is there an > API for storing attachments or should I just write directly to the page's > directory structure? You could certainly have a special homepage template and populate it from backend data, either generating the entire page every time something changes or generating an initial page that then uses macros to fetch backend data (maybe caching it if you're worried about performance). Meanwhile, if you're looking to store images inside the wiki instead of just referencing them in some conventional Web space, attachments are probably the way to go. The MoinMoin.action.AttachFile module contains functions to work with attachments in a nicer way than manipulating the filesystem directly. I'd be inclined to serve images from a vanilla Web directory unless you need the possibility for people to change them in the wiki itself, however. > - Similarly with the lists of people in a group (e.g. > http://www.linaro.org/linux-on-arm/meet-the-team/office-of-the-coo), my > intention is to build a wiki page for each group. However, if I've gone > for the aforementioned approach of storing the images as an attachment for > an individual page, can I reference that from another page? If not, I > guess the better solution would be to store all of the staff images in a > central directory and then consistently link to them as external images. You can certainly reference attachments on another page. The following should do the trick for images: <> > Any other suggestions or thoughts occur to you? > > Thanks for any input that anyone can provide on this. All of this is possible as Moin is effectively just another Web framework. The strength of Moin is in the integration with the content management it already provides, meaning that you can introduce dynamic features like this without throwing the existing collaborative editing environment away or substituting it for some inferior solution (probably involving Markdown). Let us know if you're wondering about anything and we'll try and give you pointers to the occasionally crazy things that some of us have already done with Moin. ;-) Paul From jkwight at gmail.com Wed Sep 25 04:06:36 2013 From: jkwight at gmail.com (Jim Wight) Date: Wed, 25 Sep 2013 09:06:36 +0100 Subject: [Moin-user] Suggestions sought to how best to implement this request ... In-Reply-To: References: Message-ID: On 24 September 2013 16:44, Philip Colmer wrote: > > > - The way that the lists are arranged into three columns seems to be > some CSS voodoo that I'm trying to unpick. I'm not sure how to mimic that > in MoinMoin since calling CSS directly is tricky ... > > You could try the Columns macro for that part. It was only listed under 1.6 in MacroMarket but as it has been brought up to date for 1.9 I've updated the 1.9 table. Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.colmer at linaro.org Fri Sep 27 03:45:40 2013 From: philip.colmer at linaro.org (Philip Colmer) Date: Fri, 27 Sep 2013 08:45:40 +0100 Subject: [Moin-user] Suggestions sought to how best to implement this request ... In-Reply-To: References: Message-ID: Thank you, everyone, for the replies sent. They were a great help. Management has decided/agreed to drop the multi-column display and opted for what some might consider to be an older, more traditional approach of just listing everything in a single column with a TOC at the top and "Back to top" links at each section. Easier for me to build :-). I've managed to make reasonable approximations of the team and individual pages in MoinMoin wiki markup so I'm reasonably happy with the outcome. Thanks again. Philip On 25 September 2013 09:06, Jim Wight wrote: > > On 24 September 2013 16:44, Philip Colmer wrote: > >> >> - The way that the lists are arranged into three columns seems to be >> some CSS voodoo that I'm trying to unpick. I'm not sure how to mimic that >> in MoinMoin since calling CSS directly is tricky ... >> >> You could try the Columns macro for that part. It was only listed under > 1.6 in MacroMarket but as it has been brought up to date for 1.9 I've > updated the 1.9 table. > > Jim > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: