- 02 Jun, 2008 1 commit
-
-
Leigh B. Stoller authored
-
- 20 Dec, 2006 1 commit
-
-
Leigh B. Stoller authored
converting to locally unique ids and later globally unique ids.
-
- 01 May, 2003 1 commit
-
-
Leigh B. Stoller authored
-
- 14 Apr, 2003 1 commit
-
-
Chad Barb authored
- Added 'Country' to users table - Changed "Zip" to "ZIP/Postal Code" - Reformatted Postal Address Forms
-
- 11 Apr, 2003 1 commit
-
-
Mac Newbold authored
-
- 23 Dec, 2002 1 commit
-
-
Mac Newbold authored
Fix nit with table formatting. Spread addr across table since we don't use addr2/city/state/zip anyway.
-
- 09 Dec, 2002 1 commit
-
-
Leigh B. Stoller authored
A user can request a local account on the machine he/she has dedicated to netbed. In fact, multiple people can request local accounts. They just need to fill in the form, supplying the usual personal data we require, and then some info about the node. This includes the IP and the CDKey as verification (we now save the original CDKey in the DB forever), as well as info about the node (location, processor type, connection type). They must fill out the node info for the first account request. Otherwise, it can be ignored (that is, if an entry is already in widearea_nodeinfo, we do not require those fields). Once submitted, the user has to go through the usual verification step. To approve the user, admin people get a new link on the menu to approve widearea accounts. That page looks a lot like the normal join project approval page, only is tailored slightly for widearea accounts instead of projects. Once approved, widearea users get a webonly account. Note that it can be a normal account, say if the user is also in a normal project, or if we just want to give out an account on ops/boss to this person. Just need to clear the webonly flag in the DB, and the account will be built as normal, except they are put in the "guest" group on boss/ops if not a member of any projects. There are two new tables. widearea_accounts and widearea_nodeinfo. The accounts table maps uid's to specific nodes they get an account on (see changes in tmcd). The mapping also includes a trust value (user or root, although it should be rare to give out root access) for the account.
-
- 16 Aug, 2002 1 commit
-
-
Chad Barb authored
The big one. New look; most of the changes are in menu.php3. A lot of the changes in other files are s/<TD>/<TH>/ for table headers. Also closed some tags, tweaked some table styles, etc.. No actual functionality should have changed. Will be installing soon...
-
- 07 Jul, 2002 1 commit
-
-
Leigh B. Stoller authored
-
- 01 Jul, 2002 1 commit
-
-
Robert Ricci authored
already been approved into another project will show up.
-
- 22 May, 2002 1 commit
-
-
Leigh B. Stoller authored
* Cleanup! A lot of the structure derived from the early frame days, which had a noticable (and bad) effect on how I wrote the stuff. I cleaned up most of that yuckyness. * In process, optimize a little bit on the queries. The old code did about 9 queries just to write out the menu options, and then repeated most of those queries again in the page guts. I've consolidated the queries as much as possible (to 3) and cache all the results. * Fix up problem with users who forget their passwords before verification. Basically, I fixed the more general problem of not being able to update your user info before verification/approval; users now get that menu option no matter their status. * Fix up problem of users being able to access pages before verification (but after approval) by going around the menu options. The page level check (after the menu is drawn) now checks all conditions (password expired, unverified, unapproved, timedout, and also nologins()). * Minor change in approveuser; do not show the new account to the project leader until the new user has verified his account. * Change verification method, as reqwuested by Dave. In addition to providing the key, also provide a web link to take the user straight to verification. I actually take them direct to the login page, and pass the key in as an argument. If the user is already logged in, bypass and go directly to the verify page (not the form page of course). If the user is not logged in, let him log in, and then forward the key onward to the verify page. Basically, bypass the form all the time, and just do the verification. * Minor change in showuser; Do not show pid/groups not approved in, and if the count is zero, do not draw the table headings.
-
- 13 Apr, 2002 1 commit
-
-
Jay Lepreau authored
-
- 20 Dec, 2001 1 commit
-
-
Leigh B. Stoller authored
and complaining about this week. 1. editgroup: You can now edit the trust levels for existing group members (default group too), and you can specify trust levels when adding users to subgroups. 2. approveusers: When approving users in the approval page, you can specify different levels of trust. Before, I invisibly set all the trust values the same. I also added some ordering to the DB query to group users together. 3. I added a great deal of error checking to the processing pages for both forms. I split things up into a pre/post pass. The prepass goes through all of the form args and checks them for consistency and correctness. Nothing is changed in the DB unless all checks pass for all args. Then I do a second pass and make the changes. Both scripts set the ignore_user_abort() flag to prevent the user from stopping the script and causing a DB inconsistency. 4. Added trust consistency checks as well. Rather than allow the project or group leader to set inconsistent trust levels, I look for those and just plain disallow them. You may not give different trust levels in different subgroups of the *same* project, and you may not give a user a higher trust level in the default group than in the subgroups. Both edit and approve make these checks, and the code is absolutely awful.
-
- 16 Oct, 2001 1 commit
-
-
Leigh B. Stoller authored
-
- 05 Sep, 2001 1 commit
-
-
Jay Lepreau authored
-
- 19 Jul, 2001 1 commit
-
-
Leigh B. Stoller authored
From: "Patrick Tullmann 'tullmann'" <tullmann@cs.utah.edu> Subject: Re: TESTBED: aclement janos Project Join Request First the reply-to: address for approval mails should be testbed-ops@fast (right?). Second, Austin isn't listed on my testbed user approval page. I assume Mike or a testbed person approved him (which is good because who knows when I'd get around to it. :) An option like "remove" or "ignore" or something like that for just nuking requests without a reply would be useful (I've got some guy from yahoo.com who wants to join Janos). Also, the date of the join request would be nice to know (e.g., for the above, I think he tried joining 4 or 5 months ago). he documentation above the table is out of synch with the pull-down boxes.
-
- 08 Dec, 2000 1 commit
-
-
Leigh B. Stoller authored
who the user is instead of passing ?uid to every page all the way down. Update login timeout with each useful operation (done in checklogin). Put default user name in the login box when visiting the page.
-
- 15 Nov, 2000 1 commit
-
-
Leigh B. Stoller authored
of all that duplicated goo). Clean up all the formerror code, calling standard FORMERROR() function. Get rid of all the inline DB specific constants, moving them to dbdefs.php3 include file.
-
- 06 Nov, 2000 2 commits
-
-
Leigh B. Stoller authored
-
Leigh B. Stoller authored
multiple projects.
-