UseMod Wiki: WikiSuggestions/Login

login option on edit form

Most of us don't care too much who is reading our pages, certainly less so than who is editing them. I propose that on the edit page that there be a field for soliciting the user's name on the condition that they are not currently logged in. Then, when the page is submitted the user could have a cookie automatically assigned for a new user preference profile.

The username solicitation field should be an optional requirement, and state so on the edit page, so as to avoid bogus psuedoanonymous crap. There probably should also be a link to RealNamesPlease? or whatever the local username policy is.

-- EricScheid

canonicalize user name field entry

Something I've already put in place on my wiki is a simple call to canonicalize the username field entry. This converts things like "Eric Scheid" to EricScheid and "Pat O'Flynn" to "PatOFlynn?", which for my wiki are legal usernames. This smooths the login/preference procedure - the cgi knows what patterns are legal, the user is not so concerned, the cgi can make a darn good guess what the legal version of an illegal input should be, and so uses it.

-- EricScheid

Login option in the GotoBar

An option to include an "action=login" on the GotoBar would be very useful. Users using changing workstations to access our local Wiki get confused about "Preferences" showing ever increasing UserIDs? each time they click on it. I tell them they have to remember the ID they got assigned the first time (and provide a WikiPage? with that information), but I've to include the link to "action=login" myself on the starting pages of various Wikis... --DanielHernandez

You could take advantage of the UserGotoBar entry in the config file: $UserGotoBar = "<a href=\"wiki.pl?action=login\">Login</a>"; --JimHyslop

: I've done a little thinking about the login procedure, and I think I see a good way to implement this as a configuration option. How about replacing the Preferences link with the Login link if the person is not logged in? The login page would also have a link to create a "new account", which would simply be a link to the Preferences page. This behavior would be a configuration option, so that other wikis could keep the current behavior.

: I also hope to allow people to use their UserNames? to login, so they won't have to remember their user-ID number. I'm not sure what I should do if more than one user-ID has the same username--I might just try the password for all matching user-IDs and use the first one that matches. (I considered not allowing duplicate usernames, but this could cause problems since users will forget their passwords. Eventually I should add a full "account administration" interface.)

: Another possible option would be to require new users to choose a username and password before allowing them to edit. This could be enforced by not creating a user-ID number unless they fill in the username and password, and not allowing editing unless the user has a user-ID number. This would be a configuration option for sites that want a more traditional account/login system.

: I am not sure all of these ideas will go into 0.92, but improving the login function is on my list of planned improvements. Until I read your message I didn't know of any UseModWiki site that was seriously using the login feature. (I don't even use it very often--I have a couple dozen different CliffordAdams user-IDs on the local wikis.) --CliffordAdams

: Your idea of replacing preferences with login sounds perfect. Together with allowing UserNames? instead of user-IDs it would be a great improvement in usability. I would keep things simple, though: there is no need for a fancy account administration and disallowing duplicate UserNames? is a sensible restriction. Maybe displaying a "Your user name is CliffordAdams" or "Currently logged as UserName? | Unknown" in the GotoBar of every page would be a simple way of keeping the current mechanism for the default case of "one user - one machine" and signalize the need for a login in the "one user - multiple machines" case. --DanielHernandez

: I am very directly and explicitly looking for a method to put a wiki behind some kind of password system inside a corporate firewall. I've tried working with TWiki, but the installation is very complicated for someone like me (compared to usemod... though still trying). I working with a culture in which community membership is a thing that is private to that community. It would be helpful to have a layer of wiki that would require someone to name themselves as a member before they are able to read about other people and get access to other material created within the wiki. If I could establish some level of login for, not only edit, but read too, this would be very helpful. My field of work is knowledge management, communities of practice. The good points made on WikiErase are important. These are decisions that can be made locally. -- MatthewSimpson

: Okay, so here's how I would see this ideally. 1) Admin can set $ReadPass? = 1 or 0; EditPass = 1 or 0; and AdminPass? = 1 or 0. If on, then Read, Edit, or Admin could be restricted to usernames on a siki page (e.g. WikiUsers?, WikiEditors?, and WikiAdmin?). WikiEditors? could easily have an entry on the page called "WikiUsers?" so that all readers are also editors. A person becomes a reader by setting their preferences. Setting preferences would automatically append WikiUserName? to the WikiUsers? page. Additionally, an alternative file could be set to recognize readers, editors, and admin (e.g. some other system file such as config, wiki.pl, or other text file depending on the way the admin sets it up). Thus, restriction can vary from the extremely limitted (only site admin) to very open. If a user does not have a level of access, they are redirected to set preferences page. This page could notify the end user that if they may have been directed their because they tried to access something for which they do not have permission. Does this make sense? -- MatthewSimpson

: The idea to include the name is a good one. Perhaps the Preferences link could be something like "Preferences for CliffordAdams". My main concern is that the GotoBar is getting a little long, especially for subpages. --CliffordAdams

: CliffordAdams I don't think the GotoBar is that long yet. Most of this discussion is focusing on the ability to block read/edit of certain pages to certain classes of users. My main request however is to disallow duplicate usernames. The average user may enter his chosen userid on the login/preferences page and not understand that the very same username can be used by someone else to vandalize the site. The current system is really confusing and I'd rather have no login at all. I want page changes to have a clearly identifiable owner (even it the owner name appears only in RecentChanges). --ElMoro

: May I suggest the following instead:
: * Always, always provide a Login link on the Preferences page. Document properly that users who have a valid User Id should use this to change their preferences.
: * Have the Preferences page tell you whether you have a valid cookie at this time, and instruct you on how to proceed if not.
: * Don't try to set a new cookie when the user selects Preferences; instead, create a new User Id only when the user clicks Save on the Preferences page. This spares you from having to create a [Wikipedia page creation services] lot of new Id numbers which will never be used for anything.
: Obviously, the redirect you get when you save preferences should identify the new user ID if a new one was created.
: I only came here just now from the EmacsWiki because I was unable to figure out how to login myself from another computer than the one where I created my account on that system. It is very unintuitive in the present scheme IMHO. (The EmacsWiki has a separate page explaining the problem, but this is not linked from the Preferences page in any way.)
: -- era

My usual suggestion for those who want read-level access is to use the webserver mechanisms to limit access to the wiki script. See WikiSuggestionsResolved/OldSuggestions (the "Password protect wiki with htaccess" section) for how to do this with the Apache webserver. --CliffordAdams

: Consider the following scenario. At least 1,000+ people hit a web site over the course of a year. These people are audience and can read whatever is there. About 250+ of them want to get more involved in the group. They are willing to tell others who they are and even contribute to the topic. In return for de-cloaking (de-lurking), they get access to other communication channels (deeper levels of the wiki, and other communication programs). What we have here is a distinction between an audience and a community. Using the .htaccess method, the wiki admin has to manually add each and every user. For 250+ people, this is a real painful thing for an admin to do. Is there a way have new users register themselves, password and all? -- MatthewSimpson

: There are separate packages for this. Look for stuff specific to your Web server. For instance, if you use Apache's built-in security methods, take a look at [usermanage]. Out of the box, it doesn't allow users to add themselves, but it does make user administration easier, and you might be able to coax it into doing what you want. (Keeping security out of the wiki script means you can pick and choose what works best for you.) Having "deeper levels" of security within is very un-wiki-like, but could perhaps be emulated by having separate wikis. If you really need this kind of complexity, you might want to take a look at TWiki. I tried it but abandoned it exactly because it was far more complex than what I needed. -- DanMuller

: Exactly. TWiki can do it. But I'm runnin into problems with it because it is built for Linux and not AIX (the environment I'm trying to tun it on). Plus, UseMod is faster, lighter, more wiki like, and easier to install. Having deeper levels of security within is not very un-wiki-like... it's mildly un-wiki-like. To understand this, you would have to know the social domain I'm trying to work with. Thanks for the tip on the tool that makes the manual admin easier... The goal is to automate the authentication of users... which, I'm sure you would agree, is much more wiki like. I'm simply trying to get away from the anonymous IPs, not completely, but just at one specific level. Thanks also for the encouragement... I'm still trying to think of a work around. --MatthewSimpson

: There is a freeware program called account manager lite which you can set on top of your twiki dir.
: http://cgi.elitehost.com/ JoeTennis?

I'd like to see UseModWiki not handle login, etc., at all, but rather use the HTTP authentication as the source of identity. Apache supports about a zillion means of storing usernames and passwords (file, database, LDAP). Perhaps write a CGI to allow people to add entries to the passwd file? Then configure Apache to require valid-user...

-- LairdPopkin