LoginSuggestions

MeatballWiki | RecentChanges | Random Page | Indices | Categories

[See MeatballWikiSuggestions for other categories of suggestions.]

Logins should fetch profile from server.

It seems that when one "logs in" from the Preferences page, instead of loading the person's user profile from the server, it merely fetches the User ID and then writes over it with the default settings on the preferences page. It would be better than when I log in, the server remembers my preferences.

: At least one of us is confused. One doesn't "log in" from Preferences. One sets a password on Preferences that one can use with "action=login" somewhere else. What were you trying to do? This isn't an official feature yet since it isn't documented. --ca

Ah. Didn't know about MeatBall:action=login. Sorry. Perhaps you really should put that Login link on the link bar.

: Logins should be rare, so they probably don't belong on the link bar. The Preferences page is probably better. I'm already planning to add a "Help" link to the bar, which would bring the default number of links to 4 (+1 if you are viewing a subpage, and +1 if you turn on the Random Page option). --ca

The big problem is remembering my user ID. Going through RecentChanges and reading the TITLEs on the UserNames is one solution, but it's impoverished. If we rely more and more on user profiles for such things as display preferences or (sigh) authenticated log ins, there needs to be a good way to match a UserName to an ID.

One way is to perform a search through the User ID database for a given UserName. Actually, that might be sufficient if you add a description field to the preferences. A profile for a Palm Pilot may be different than one on a desktop; a profile at work may be different than one at home. The description could trivially differentiate the various IDs that map to a given UserName.

In this way, we continue to AvoidIllusion that UserNames are non-forgeable too, as anyone can assume anyone else's UserName. -- SunirShah

: I've pretty much settled on two fields for the login screen:

Password

: If you want multiple profiles you could simply set multiple different passwords like "foo123palm", "foo123cellphone", "foo123desktop". The first ID matching both the name and password will be used. You could even remind yourself of the suffixes on your home page. (I might even allow the login name/number (but not the password) to be part of the login URL, so you could have links like MeatBall:action=login&user=SunirShah to quickly log in.)

: Finally, in case you forget your password and lose your cookies, I hope to implement a user-info email address (which you would set when you have your cookie). If you forgot your password (or never set one and lost your cookie), you could request that a new password be auto-generated and emailed to your registered address. (At first the email may be sent manually to minimize the risks of third-party email. Some people treat *any* unsolicited email very seriously.)

: These login improvements are unlikely to make it into 0.90 (if you want a 0.90 release this year ;-), but they might make 0.92. --CliffordAdams

The recent name/id/password discussions may be confusing, so here's a clarification of the current state of UseModWiki (and Meatball). At this time (version 0.88 on November 1, 2000), the UserName is only some user-provided information placed on RecentChanges. Users can currently change their UserName at will, and the only significant restriction (besides length) is that it must fit the LinkPattern. The user-ID number (like 1003) is a unique identifier generated when a user visits the "Preferences" page. The user-ID is used for any information related to identity such as retrieving/storing preferences or determining if an edit is by a new author (for differences).

The "randkey" is an internal validation code that is never displayed to the user (it is a 9-digit number). The randkey is generated along with the user-ID and is stored in the preferences file on the wiki server. In some ways the randkey is most like the passwords on other online systems, except that it is automatically generated and not (currently) changable by the user. User cookies currently contain only the user-ID number, the randkey, and a version number (to make future upgrades easier). Whenever a cookie is returned to the wiki, the randkey sent by the client is checked against the randkey stored on the server. If they match, the cookie is considered valid and the user-ID is set to the cookie's user-ID.

The "randkey" system works well at being transparent, yet it provides fairly strong security against someone else stealing one's user-ID and/or altering one's preferences. (This is less important now, but later versions may add significantly more preferences like bookmarks, non-public draft pages, and other features.) The main problem is that it relies on the cookie information. If the user's cookies are not available (on another browser or system) or destroyed, then the user's preferences become inaccessible.

The (currently unfinished) login system with a user-settable password is intended to fix the problems of the "randkey" system. (See WikiAccessLevels for the current login procedure.) It only requires extra work for those who care about the problem, while not requiring a login step for other more casual users. If a password is set, one can use that password from a new system to request that the id+randkey cookie should be sent to the new system. (If you do not set a password, or if you unset the password, then the cookie will not be sent to any other systems.) In a sense, the "password" is really a password for one's "randkey" data (which is the *real* access-control-key for your data).

[To be continued... Later I'll try to explain some options for future work. --CliffordAdams]

I question the primary concern being security instead of usability and functionality since there have been no attacks yet.

: I think you might care more about security if your user-ID was able to ban entire IP networks from accessing the wiki. Unless the wiki mistrusts everyone equally, some form of recognition may be desirable. Many SoftSecurity principles work better in communities where people can recognize each other. Also, suppose Meatball was attacked right now from multiple sources. In that case I could fairly easily allow only "old" user-IDs to edit until other defenses were set up. (This would be an alternative to making the wiki read-only for everyone.) A purely anonymous approach (like read-only for all) seems to punish everyone and hope the attackers become bored before the good users leave. --CliffordAdams

[CategoryIdentity]

LoginSuggestions

Discussion