User Registry
The VTS hosts secure 1-to-1 applications, meaning that each visitor
- each USER - needs a password, ID, contact data and preferences.
This project will finalize a logical model of such data
started last year; explore its uses in security, applications,
etc.; consider ways to implement the data model most effectively;
and alpha test at least one of the options ASAP.
November News
Early this month, we decided MJP web apps really need such powers on
a distributed basis, implying a single sign-on
capability. Craig followed up his sourceforge initiative with a
MySQL database at John's site. As of 11/26, Dan posted enhancements
#1 and #2, advancing the UI level.
What is a USER?
Conceptually, each instance represents a person. It has a persistent
identifier ("UID") uniquely assigned by this site, to which are
logically attached email address, login password, and other
identity-related Strings. The User sets them at registration time,
and may later reset their values after any successful log-in.
Other USER properties (TDBL) are allowed as "preferences". They
can be stored separately in various scopes using the (unique) UID,
which is universal, and will never be reused and changed.
I. What happens at REGISTRATION Time?
You can enter Contact data and a password. As of 11/26, you can
now click the [Register] link above to try this out!
II. What happens after LOGIN Time?
You can edit your own registered data. As of 11/26, you can now
click the [Register] link again, AFTER logging in, to try this.
The USER should also be able to logout to prevent others
nearby from acting in his name. Click the [Login] link
again, AFTER you logging in, to try this.
III. What happens at LOGIN Time?
The current site has login logic that takes passwords only.
This lets UIDs be used internally and enables security, but
several flaws remain. I'd like to fix
them and support enhancement #3 as soon as reasonable:
Enhancement #1 of 11/26: This replaced an admin-only list
of users with a web-expandable, web-editable CSV file, and linked
three new pages (for I and II) into the old booth header and login
page. This lets the base of registered users grow at login time,
and update its own contact data later at need.
Enhancement #2 of 11/26: One of the three pages lets a user
who forgets his password get it emailed to him. This works, and
programmatic search logic exists, but the reply is manual and slow.
To make it faster, we need programmatic email.
Enhancement #3: design and add logic to handle "preferences" in
a flexible way, which lets each USER self-specify various kinds
operational desires, plus memberships in various
groups. Such things in
turn can decide how each web app acts and appears from login time on.
Note: We have new DBMS-based options for storing preferences
and associations, which we can debate in our mailing list.
The old
options are record sets and
metadata.
Enhancement #4: add logic to set/check a cookie that will let
the USER be welcomed by nickname, enhance security, and eliminate the
need for a linear login-time search to confirm a password.
Enhancement #5: adjust the login logic to ASSUME a correct password
if the cookie exists, unless (a) some USER preference disallows this or
(b) the USER tries to go someplace REALLY secure, like some adminpage
where things can be changed.
|
