1. 01 Oct, 2002 1 commit
    • Robert Ricci's avatar
      Change user verification keys. Verification key is now an md5 hash · a4e8ca5b
      Robert Ricci authored
      of a random number, as suggested in the php manual. This number
      is stashed in the database, in the new verify_key column in the
      users table.
      
      Rename the functions that generate and get the keys, and move from
      defs.php3 to dbdefs.php3, since they're now DB operations.
      a4e8ca5b
  2. 16 Sep, 2002 1 commit
  3. 07 Jul, 2002 1 commit
  4. 12 Jun, 2002 1 commit
  5. 28 May, 2002 2 commits
    • Leigh B. Stoller's avatar
      Fix syntax error. · cd2094d5
      Leigh B. Stoller authored
      cd2094d5
    • Leigh B. Stoller's avatar
      Ug, finish up the verify user changes. I can't believe I forgot to do · ff33dc1e
      Leigh B. Stoller authored
      this last part! Senility is setting in. Anyway, change join project to
      not send the email to the projleader when the user is new; let that
      happen out of the verify page when the newuser does the verification.
      Basically, duplicate some code to generate the email message.
      
      XXX: I have not fixed up approveuser.php3 to check to make sure that
      the user has been verified. Basically, for this to happen the proj
      leader would have to generate the URL by hand, and thats not likely,
      and not really a dangerous thing anyway. However, it is confusing.
      ff33dc1e
  6. 22 May, 2002 1 commit
    • Leigh B. Stoller's avatar
      A large set of authorization changes. · d2360b6d
      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.
      d2360b6d
  7. 13 May, 2002 1 commit
  8. 14 Feb, 2002 1 commit
    • Leigh B. Stoller's avatar
      A morass of form changes. The main goals are to avoid the loss of info · 9ac3d870
      Leigh B. Stoller authored
      when backing up (cause of an error that needs to be fixed) since not
      all browsers handle this the same. Instead, redraw the form with all
      of the original info and a list of error messages at the top.
      Conceptually simple change, but it turns out to be a pain to implement
      since you need to combine the form and processing code in one page
      (well, its just a lot easier to do that), and then change all of the
      forms to deal with a "default" value. That is, each different kind of
      input tag (text, radio, select, checkbox, etc.) requires slightly
      different changes to do that. Lots of forms, lots of entries on the
      forms, and its a long slow tedious process. Much nicer though, although
      the code is a bit harder to grok. At the same time, I added a lot more
      sanity checks of the information being passed in.
      
      The other change is to deal with how browsers handle the back button
      on a form thats been properly submitted. Not all browsers use
      the cache dire...
      9ac3d870
  9. 16 Oct, 2001 1 commit
  10. 05 Sep, 2001 1 commit
  11. 04 May, 2001 1 commit
  12. 18 Apr, 2001 1 commit
  13. 15 Nov, 2000 1 commit
  14. 03 Nov, 2000 1 commit
  15. 02 Nov, 2000 1 commit