|
In lugnet.dear-lego, Brad Justus wrotes:
> [...]
> At this point, we can only ask for the support of the LEGO community; if
> you've got suggestions as to how we can prevent this sort of thing from
> happening in the future, we'd welcome them.
> [...]
I've been cogitating on this from a technical standpoint and I think I have
come up with a general workable solution, all things considered. I agree
that if something can be done, it should be done.
What I want most to avoid is having to instate NNTP passwords, which are a
huge logistical mess and generally make life much less pleasant for users.
(And some newsreaders actually don't even support NNTP authentication.)
I think the thing to do is let user verification/authentication be up to the
discretion of the user who's posting: treat it as an advanced or enhanced
web-based feature. Most typical users probably won't care too much one way
or the other, but Brad, obviously, given last Saturday's mess, would always
want this enabled, so that he knows that we know it's really him.
So here are my thoughts:
There is the 'X-Real-Life-Name' header field which is inserted automatically
into new incoming messages. It gives a bit more information about someone if
they're using a screen name, nickname, alias, etc., but it doesn't actually
authenticate someone via a password. But something like this could.
A header field 'X-Member-ID' could be inserted by the web interface if and
when someone is a member signed-in at the time they post. Subsequently,
when articles are displayed, this field would be interepreted in some way and
would give a link to the member's page, perhaps with some small additional
graphic image or other mild attention-grabber.
This would allow people with multiple email addresses to continue posting
from any of those addresses without having to worry about configuring
anything else, and could all be made to happen automagically and
transparently.
A second (optional) level of protection could be voluntary blocking of
one's own email-address & name to other users -- i.e., someone could ask
the system not ever to let anyone post using their name & email combination
unless the poster was actually signed in as that user. Blocking based on
name & email together (not separately) would certainly not prevent some
other person coincidentally named Brad Justus from posting, but we wouldn't
want to prevent that anyway.
Since LUGNET member passwords are not sent via email but rather by snail
mail, member packets of TLC employees could even be sent to a LEGO Company
postal address, further proving the reality and validity of the person behind
the identity.
Now, all of this assumes that Brad and other TLC employees who wanted to
participate (without fear of being imposterized) would be willing to sign up
as members and post only through the web interface, so this solution may not
be feasable. But short of kludging up some other authentication system, I
think this is really the only way to go.
In terms of being "members," BTW, I probably should allow for TLC to be its
own "user group" of people with its own roster and so forth. I set up the
member cookies in such a way that any person could actually belong to any
number of user groups of people. When you sign in as a LUGNET member, your
cookie is named "/". Signing in as a LEGO Company member (as opposed to a
LUGNET member) would give some other cookie, perhaps named "/lego/". And if
someone is a NELUG member and NELUG was having LUGNET handle its membership
roster, then signing in as a NELUG member would give a cookie named
"/org/us/nelug/". So quite a bit is possible.
--Todd
|
|
Message is in Reply To:
| | Re: What the F.......
|
| Let me stop this right now. Whoever posted claiming that LEGO Direct is a scam was not me; and the sentiment expressed in the post could not be more wrong. LEGO Direct is a very real undertaking of The LEGO Company and we are very committed to it -- (...) (25 years ago, 12-Dec-99, to lugnet.dear-lego) !
|
43 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|