Re: Security

"Ken Kahn" <kenkahn-0OjJFJ8UyiNWk0Htik3J/[email protected]> Tue, 27 Jan 2004 11:25:39 -0000
Newsgroups gmane.education.weblabs.webreports.uedesign
Message-ID <244201c3e4c8$4b811a10$c400a8c0@LAP68>
One more thing we talked about in London. That all users are required to
be associated with a school. So if some user is misbehaving we know who
to contact. Also those responsible for a school should be able to spot
any suspicious members. Notification of new members to teachers or
researchers responsible for a school would be nice but if it is much
effort then probably not worth it. Note that if there are some
researchers who don't have a "school" there can be some other
organization instead.

Best,

-ken


----- Original Message ----- 
From: "." <jesperh-auIyqT/[email protected]>
To: "WebReports" <webreports-uedesign-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Sent: Tuesday, January 27, 2004 9:35 AM
Subject: [Webreports-uedesign] Security


> I have started to close up the site to non-members. Virtually nothing
will
> remain visible to those who do not log in.
>
> The current suggestion for new members is to implement a scheme where
any
> new member must be cleared by someone with local authority. My fear is
> that this will prove to cumbersome in practice: we must implement this
new
> scheme on the server, distribute the authority, and most importantly:
> teach all possible teachers/researchers how to use this feature
properly.
> My experiences so far indicate that this will not be easy.
>
> I would thus suggest that we start with a simpler approach: to the
> "register-new-user-form", we add an extra password field. This
password
> will be distributed among us teachers/researchers, and is required for
a
> new user to be registered. The teacher can make this password known to
new
> users in an appropriate way.
>
> Although this certainly does not stop NSA from entering our site, I
would
> think this is good enough for us to show potentially worried parents
that
> only people we know can join the site. The main risk, as I see it, is
> that this password over time is "leaked" to people outside our
project,
> but it would be easy to change the password from time to time, and
then
> redistribute the new password.
>
> Implementing this change would be easy for me to do. What do you
think?
>
> Jesper
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Webreports-uedesign mailing list
> Webreports-uedesign-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/webreports-uedesign
>
>




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn