On Thu, 10 Mar 2011 13:42:26 -0600
Dan McGee <[email protected]> wrote:

> On Thu, Mar 10, 2011 at 1:24 PM, Dieter Plaetinck <[email protected]> wrote:
> > On Thu, 10 Mar 2011 19:17:37 +0100
> > Tom Willemsen <[email protected]> wrote:
> >
> >
> >> > * there will need to be some kind of "are you human test"
> >> >   on the input form (a simple question/response check might do fine,
> >> >   like "which Linux distro is this about? (just the 4-letter word)")
> >> > * I would prefer even some sort of authentication.  if there was a way
> >> >   to allow people to authenticate with their bbs or archwiki login, or
> >> >   even get cookies from the wiki (does archlinux.org get the cookies
> >> >   from wiki.archlinux.org?)  this will be needed to have some
> >> >   credibility for entries, as well as a way to get back to the user if
> >> >   I have any questions about their report.  also if we have this, we
> >> >   don't need the 'are you human' test.
> >> That would be pretty cool, I only know it _should_ be possible if we
> >> just grab credentials from the bbs/wiki/aur database, but I think that
> >> would be beyond the scope of just the app I'm writing. Of course I could
> >> look at how (re)captcha works.
> >
> > I think this app needs authentication (for webbased form input), there are 
> > 2 reasons in my previous mail.  Why do you think this app doesn't need 
> > authentication?
> > captcha isn't needed if we have authentication.
> 
> Why does this need authentication at all? I'm totally confused on this one.
> 
> 1. No way this will ever integrate with BBS/Wiki login unless you get
> single sign-on working for everything anyway, so just forget that
> idea. That has been a dream feature request for years
> (https://bugs.archlinux.org/task/10703). If you want integration, then
> this app should be a a) forum thread or b) wiki page.
> 2. Credibility- we ask for a name and email address here, so that is
> something. You'll be able to see bogus results if they come through.
> I'm not sure how this form is any more likely to result in spam than
> posts to the ML, and if it does, don't accept forms without comments,
> etc. There are plenty of ways to avoid garbage.

okay, so no authentication reuse.
then i guess the next best thing is to ask a (nick)name, email address and 
response to a simple "are you human" question. that should work well enough, 
except it would allow people to purposely add "everything is okay" reports with 
a bogus name/ email address, which would cause me to mark iso's as "verified 
enough" and make an official release of crappy isos. (or the inverse: they can 
mark as everything as broken).  if users would be authenticated I think there 
would be less chance for abuse.

> > AFAIK templates/public/download.html is a static page, maybe looking at 
> > that can help you.
> 
> Hardly static, and I hate the damn thing as people ride my ass if I am
> an hour late updating and deploying it. I have to edit it every time
> we do a release which is ridiculous, so please please please don't
> follow this. If anything, and I have done this on other Django
> projects, we should add a "StaticContent" type model that allows
> arbitrary admin controlled bits and pieces of content to be displayed
> on our various pages.

I think with static you mean "rarely/never gets updated".  I meant "not 
dynamically generated"...

But yeah, I wouldn't want to force you doing work whenever I do a typo fix on 
the page. OTOH if deploying a small update is more work then 1 simple command, 
then there's something wrong with our method of deploying. Imho there should be 
a command that you, I or any other dev can execute to deploy updated archweb 
code. and the tree should always be in a state that it can be pulled from and 
put live right away (maybe by using a `production` branch?), and when there are 
invasive changes, needing schema changes or whatever, these should be brought 
into `production` branch when they are being enabled live by someone who knows 
what he's doing. (i.e. you).

However, if that is not something we want (it would for example imply I need 
push access to the repo) or have time to setup right now, I can live with the 
next best thing: maintaining the help page on the wiki. (I don't like the idea 
of managing the page content through the webinterface, I want version control, 
so let's keep this webapp simple and let's not poorly reinvent a wiki)

Dieter

Reply via email to