Specifications for the user management module for Collab. Try to keep this module reusable for other applications needing user management with no database. A user consists of four data points; userid, username, email address, and password. All four data points are kept in the directory usernames in a text file username.txt like this 000000 (userid) username@example.com (email) !@#$%^ (hashed password) username (not sure this is needed - try to eliminate) (side note - It is also possible to reference the username by userid in the userids directory as a text file 000000.txt that contains only the username. This way any post link can cross reference the username. This is not really needed for user management and should not be used in this part of the program.) --- User management functions are: Create account Login Logout Reset password - Handles both forgot password and change password. Change username and email address Breaking these out: Create account User enters username, email address, and password. A confirm string is generated. The password is encrypted. The userid is assigned sequentially and text files are created in the userids directory, userid.txt, which remains empty until confirmed and in the pending directory, confirmstring.txt which will become username.txt on confirmation. confirmstring.txt is filled with the users data; userid, email address, password hash, and username. A confirmation email is sent with a link to confirm the account. The link in the confirmation email runs a program. The pending file is changed to username.txt and moved into the usernames directory. The id can be read from that file and the userid.txt file should have the username added to it. A file email_address.txt will be created in the email directory with the username in it. Check for unique email or password resets will be ambiguous. The userid folder should be created with an empty profile.txt file in it. The user should be informed on the web and via email. A cron job is run daily removing zero length id files and files in the pending directory that are over a day old. (Or some alternative. There might be a daily job that does this and other maintenance/sanity checks.) Login The user fills in username and password. The password is hashed and compared to the hashed password in the username.txt file in the usernames directory. If there is a match the username and userid are stored in session variables. Also a username cookie is written so when the session variable times out the session variable can be refreshed from the cookie. If there is no match the login screen is displayed again with a message. Note - The cookie does not auto login a user. It is only used when the session variable times out after the user has logged in. (side note - Do not assume that cookies are enabled writing the application code. Session timeouts can occur during data entry and steps should be taken so that the user does not lose text.) Logout Probably still need a logout button in case someone sits down to write at a computer where someone else is logged in. No need to make them close their browser to start a new session or to even assume they understand that is what they need to do. The way this is setup in any given browser session only one user is supported. There is a possible problem where a second user logs in, a cookie is written, the first user times out, and gets relogged in as the second user. Reset password - do email address first The user enters username or email address. If username is entered the email address and is found in the username.txt file an email is sent with a link to reset password for that username account. If email address is entered the username is found and the email is sent. Maybe create an emails folder with text files email_address.txt containing the username for random access into the username by email address. After the user changes the password the password is hashed and written into the username.txt file. Change username and email address. Exactly like reset password except the user is sent to a prefilled screen to change username and/or email address. Changes are written to the username.txt file and username.txt and email_address.txt are renamed as needed. Also userid.txt is updated as needed. --- Security The usernames, userids, and email addresses should not be available for public reading on the internet. A directory listing on the email_addresses folder will expose users email accounts. This folder should probably not be called email_addresses or contacts. Maybe uema or uc. Still anyone with access to the code can find this. I fixed this with a html redirector in index.html in each directory. I also added .htaccess files to the userids, usernames, and emails directories. Deny from all