OpenGuides-Dev

openguides-dev@lists.openguides.org

701 discussions

Re: [OpenGuides-Dev] Dealing with wiki spam
by Dominic Hargreaves 18 Jan '05

18 Jan '05

On Tue, Jan 04, 2005 at 08:27:04AM -0500, IvorW wrote: [could you fix your linewrapping, thanks] > Just having a braindump on this hot topic. > > 1. We should look to improving the user login side of OG/CW. Currently, > you just go into the "preferences" page and set your ID to whatever you > want. > > If we have a password associated with the ID, this will hopefully > prevent impersonation and other suchlike abuses. OK so the form may be > sending the password in clear text The way I see this working is that a login module can be plugged in, and if one has logged in somehow, an "authenticated" flag would be set in edits, such that we can be sure that that user really did submit the change. That user would then not be presented with the option of specifying a username. This is also important for copyright control. It would be far too easy to claim infringement if submission is entirely anonymous, but this would of course be up to the individual admin. I wouldn't want to require login, but maybe the copyright could be assigned to the Guide if the change was made anonymously? (I am now defining Anonymous to included non-authenticated usernames). This is something I've been meaning to look at for absolutely ages; initially I was thinking of integrating with basic auth, but I think a decent cookie-based session login will be more useful (suggestions for modules to use?) See <https://rt.cpan.org/NoAuth/Bug.html?id=9340>. > 2. Ideally we want OpenGuides to stay wiki, i.e. allow anonymous > contributors. But, there's no reason why it needs to be a > WorldWideWiki, open to Chinese and Russian spammers. We could restrict > the anonymous login from anywhere but the same country as the guide > is located in, decoding the country from the IP address (I'm sure > there's a module or three that does this). Of course we still want > genuine contributors to add content from abroad - but they can always > register and log in :). I think this is going to be more hassle than use. I am less concerned about spam than impersonation. There's nothing to stop a spammer registering and logging in, so I see this as a different problem. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

1 0

RE: [OpenGuides-Dev] Meta metadata?
by IvorW 11 Jan '05

11 Jan '05

> -----Original Message----- > From: openguides-dev-bounces(a)openguides.org > [mailto:openguides-dev-bounces@openguides.org]On Behalf Of Rev Simon > Rumble > Sent: 11 January 2005 10:24 > To: openguides-dev(a)openguides.org > Subject: [OpenGuides-Dev] Meta metadata? > > > Hi folks. > > I've been thinking perhaps OpenGuides needs the ability to have a > comment or similar for some of its metadata. For example, > this node is > about a long-thin object: > http://engineer.openguides.org/?Manchester_Ship_Canal My thoughts about this are to have a new type of node called a route. Such nodes contain a list of (x,y) or (lat,long) pairs tracing a route. These are joined together by straight lines when displaying on SVG or suchlike. Another note type with a collection of points is a boundary. This has the distinction of (i) being cyclic and (ii) having an inside and an outside. There are also locales, which are collections of points. </braindump> > > This makes it hard to provide coordinates. You could just > make a point > of always picking the middle of such an item, but what if you > wanted to > pick out the most interesting point? > > Consider the Cloaca Maxima in Rome > (http://en.wikipedia.org/wiki/Cloaca_Maxima -- no node in TE > yet). It > runs through the entire city but the most interesting point, from a > tourist POV, would be its entrance into the Tiber. > > So I'm thinking the best way to handle this might be multiple sets of > coordinates with comments describing their purpose. So for the > Manchester Ship Canal, you might say "Boat Museum on Manchester Ship > Canal". Cloaca Maxima you might say "Entrance of Cloaca Maxima into > Tiber". One option would be to make each point have a placeholder page, like the "bus stop" pages. It's debatable whether we need that level of detail, unless we can automate the process: GPS upload => LWP Some examples like stations on a line, clearly should have their own page. My £0.02 Ivor.

1 0

[OpenGuides-Dev] Meta metadata?
by Rev Simon Rumble 11 Jan '05

11 Jan '05

Hi folks. I've been thinking perhaps OpenGuides needs the ability to have a comment or similar for some of its metadata. For example, this node is about a long-thin object: http://engineer.openguides.org/?Manchester_Ship_Canal This makes it hard to provide coordinates. You could just make a point of always picking the middle of such an item, but what if you wanted to pick out the most interesting point? Consider the Cloaca Maxima in Rome (http://en.wikipedia.org/wiki/Cloaca_Maxima -- no node in TE yet). It runs through the entire city but the most interesting point, from a tourist POV, would be its entrance into the Tiber. So I'm thinking the best way to handle this might be multiple sets of coordinates with comments describing their purpose. So for the Manchester Ship Canal, you might say "Boat Museum on Manchester Ship Canal". Cloaca Maxima you might say "Entrance of Cloaca Maxima into Tiber". Just some idle thoughts. -- Rev Simon Rumble <simon(a)rumble.net> www.rumble.net The Tourist Engineer Because nerds travel too. http://engineer.openguides.org/ Trickle-down theory--the less than elegant metaphor that if one feeds the horse enough oats, some will pass through to the road for the sparrows. - J. K. Galbraith

1 0

[OpenGuides-Dev] Hackfest cat-herding
by Earle Martin 10 Jan '05

10 Jan '05

So then. It looks like we weren't able to sort it out for this month, so let's do the get-together-and-hack-on-stuff thing this January, 2005. How about the last weekend of the month (Sat 29/Sun 30)? BTW - if it's to be at my place, we can accomodate one overnight (or two if they share a futon!) - first come, first served. Reply here if you're up for it. Cheers, Earle. -- Earle Martin http://downlode.org/ http://purl.oclc.org/net/earlemartin/

5 5

[OpenGuides-Dev] Re: [cpan #6386] [Comment] Search Engine has an issue with international characters
by Kake L Pugh 09 Jan '05

09 Jan '05

(Quoting the whole thing since most people won't have read the RT thingy.) On Sun 09 Jan 2005, via RT <comment-OpenGuides(a)rt.cpan.org> wrote: > This message about OpenGuides was sent to you by DOM via rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=6386 > > > This is a comment. It is not sent to the Requestor(s): > > [IVORW - Sat May 22 17:14:21 2004]: > > > [MRAMBERG - Sat May 22 17:01:40 2004]: > > > > > Namely, it doesn't support them, so searches for things like > > > gr�nerl�kka > > > and gr�nland are moot. > > > > I will look at expanding the allowed character set for search strings > > to take into account internationalization. We need to see if there are > > issues with Search::InvertedIndex, and make sure that it tokenizes in > > an i18n way. > > Work on this should probably be concentrated on Plucene - see other utf8 > bugs in OpenGuides though. If we want Unicode searches to work we may need to canonicalise characters before indexing (and also before searching the indexes of course) since plenty of characters have more than one Unicode code point (eg e-acute can be "e-acute" or "e" + "combining acute". I'm not sure how Perl copes with this issue - anyone? I was thinking if we're taking the trouble to do this it might also be a plan to canonicalise further, eg store and search for "e-acute" as simply "e". Not everyone can type accented characters so either the data or the search term could be typed as plain "e", and it would be nice to Do The Right Thing. I think the right place to do this could be in a new CGI::Wiki::Search::* that could sit on top of either Search::InvertedIndex or Plucene or even a simple table in the database. I'm not working on this at the moment, just occasionally thinking about the issues. Kake

1 0

[OpenGuides-Dev] A few formatting issues
by James Green 09 Jan '05

09 Jan '05

Hi all, and a Merry Christmas! I've been fiddling about with the layout of nottingham.og.o, and have a few minor issues with the templates I'd like to bring up: * It appears there is no div that covers all the actual content of a node; the 'content' div seems to include the navbar as well. Is this intentional? For what I was hoping to do with the layout, these being separate divs would probably be really useful -- either for the content div to stop including the navbar, or for some other div to be created including the rest of the content div, after the navbar. * There are two search boxes on every page (navbar, footer). Would it be easy to add a config option to not have one of them, or just lose the footer one altogether, or something? I think the one in the navbar is more immediately visible, so I'd probably prefer to keep that one. (There's probably also an argument for a special one in home_node.tt somewhere, for guides which have no navbar on the front page, or something.) * The Recent Changes box on the front page looks quite cluttered, and is bigger than I'd like; one solution to this would be to lose most of it, just retaining the node names, and maybe the marker proposed in <http://rt.cpan.org/NoAuth/Bug.html?id=9068>. But, I realise some guides might want the full version of this box, as it stands. So I suggest a new config option (yes, I know, another question at install time...) called something like minimal_recent_changes which can then be used in the templates to remove the 'fluff' from this box as appropriate. I'm also not convinced of the point of the "edit this page" link in the recent changes box, but I assume that's there for a reason I've not thought of yet! As another alternative, could the recent changes front page box be made optional altogether? I assume this would be relatively easy to do, and I think this is if anything a _more_ useful option than the navbar being optional. There's probably other stuff, but it's 3am. I'll follow up to this message next week, no doubt :-) Cheers, James. -- jkg((-.+)?@(|the\.)earth.li|@(jimbo|wonky)\.org\.uk|03u@cs\.nott\.ac\.uk) A celebrity is a person who is known for his well-knownness.

5 9

[OpenGuides-Dev] Bug summary
by Dominic Hargreaves 09 Jan '05

09 Jan '05

Quite a few bugs have accumulated that aren't yet been worked on (many of them wishlist bugs). Just in case people haven't seen them, here's a summary of things that need looking at (I'm excluding the utf8 stuff for the time being): https://rt.cpan.org/NoAuth/Bugs.html?Dist=OpenGuides Normal: 6389 Deleting Strange locale nodes https://rt.cpan.org/NoAuth/Bug.html?id=6389 8814 Undeletable garbage nodes on london.openguides.org https://rt.cpan.org/NoAuth/Bug.html?id=8814 8852 node.tt doesn't look for osie_x https://rt.cpan.org/NoAuth/Bug.html?id=8852 9390 Bug handling <pre> https://rt.cpan.org/NoAuth/Bug.html?id=9390 Wishlist: 8203 More helpful Create a page in this category link https://rt.cpan.org/NoAuth/Bug.html?id=8203 9231 Table of contents https://rt.cpan.org/NoAuth/Bug.html?id=9231 9286 Wanted nodes count https://rt.cpan.org/NoAuth/Bug.html?id=9286 9313 mod_perl support https://rt.cpan.org/NoAuth/Bug.html?id=9313 9315 Merge longon.og.org templates https://rt.cpan.org/NoAuth/Bug.html?id=9315 9340 Basic auth integration https://rt.cpan.org/NoAuth/Bug.html?id=9340 9380 Custom metadata fields https://rt.cpan.org/NoAuth/Bug.html?id=9380 9555 Edit page category/locale selection https://rt.cpan.org/NoAuth/Bug.html?id=9555 9556 Mandatory comment field https://rt.cpan.org/NoAuth/Bug.html?id=9556 4077 Review date field https://rt.cpan.org/NoAuth/Bug.html?id=4077 Cheers, Dominic.

1 0

[OpenGuides-Dev] Re: [OpenGuides-London] Validating categories
by IvorW 09 Jan '05

09 Jan '05

Cross-posted from OG London to OG Dev ----- Original Message ----- From: "Andrew Black" <andrew3(a)black1.org.uk> To: "Discussion of the Open Guide to London." <openguides-london(a)openguides.org> Sent: 09 January 2005 09:57 Subject: [OpenGuides-London] Validating categories > > Thanks Kake for deleting the categories that were duplicates. > > I would find it useful if the edit screen gave you a chance to view > existing categories. This would help encourage reuse of existing ones > rather than create duplicates (library/ies or Wi-Fi / WiFi ). > On a similar topic. I would like to see "*Comment about your changes:" > as a mandatory field (unless you have selected minor tidying). It is > terribly easy to save a change forgetting to add the comment.* I did moot the idea of a select dropdown and add/remove buttons for the categories and locales, on the edit page. These are the kind of thinks that look and work better in (Java|Ecma)script though, which might be bad for browser compatibility. What do others think?

2 1

[OpenGuides-Dev] Wishlist: custom metadata fields
by Earle Martin 05 Jan '05

05 Jan '05

https://rt.cpan.org/NoAuth/Bug.html?id=9380 Thoughts? -- Earle Martin http://downlode.org/ http://purl.oclc.org/net/earlemartin/

4 3

RE: [OpenGuides-Dev] Dealing with wiki spam
by IvorW 04 Jan '05

04 Jan '05

Just having a braindump on this hot topic. 1. We should look to improving the user login side of OG/CW. Currently, you just go into the "preferences" page and set your ID to whatever you want. If we have a password associated with the ID, this will hopefully prevent impersonation and other suchlike abuses. OK so the form may be sending the password in clear text, but the paranoid could always wrap the login page in https. The authenticated values result in a session cookie, much as happens with the preferences at present. It's probably best if the cookie does not hold much - just a session ID: index into a session table with a foreign key on a user table to retrieve preferences server side. Secondly, the first password should be emailed to a valid email address. This also enables use of a "forgotten password" link or button on the login page. An alternative to this would be manual "vouching" for new user requests. More work for the admins, but less work for the developers possibly. 2. Ideally we want OpenGuides to stay wiki, i.e. allow anonymous contributors. But, there's no reason why it needs to be a WorldWideWiki, open to Chinese and Russian spammers. We could restrict the anonymous login from anywhere but the same country as the guide is located in, decoding the country from the IP address (I'm sure there's a module or three that does this). Of course we still want genuine contributors to add content from abroad - but they can always register and log in :). My £0.02th Ivor.

1 0

← Newer
1
...
41
42
43
44
45
46
47
...
71
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

OpenGuides-Dev