How the SBMT does its model/data access control. See also Julie Napp's guide on the Davis drive for how to manage the passwords. THIS IS TERRIBLE AND NEEDS TO BE COMPLETELY REDONE BUT THIS IS HOW IT WORKS: First there are the Apache .htaccess files: 1. Change the centralized server htaccess restrictions as needed. This part is well organized and easy to deal with. Edit the file: /disks/d0180/htdocs-sbmt/internal/.htgroups-sbmt It's self-explanatory and clean. Add/remove users to/from groups or add/remove entire groups. 2. Enforce this policy by putting the following content in the .htaccess file in any directory you wish to protect: AuthType Basic AuthName "SBMT" # Optional line: AuthBasicProvider file AuthUserFile "/disks/d0180/htdocs-sbmt/internal/.htpasswd-sbmt" AuthGroupFile "/disks/d0180/htdocs-sbmt/internal/.htgroups-sbmt" Require group PowerUsers Substitute the real group name on the last line, and keep PowerUsers, i.e., keep everything else the same. This will protect subdirectories of the directory as well. 3. Also put an .htaccess file with the same content in the metadata directory at the same level at the corresponding model metadata. (This assumes the whole model is protected, not just say images). To help with this, the directory /project/sbmt2/sbmt/data/accessControl has a script sync-htaccess.sh that can rsync the .htaccess files under a given directory to another. At this point, whatever else happens, users without a password should not be able to access the data you have protected. So if you get this far, you're at an acceptable minimal level of success. To make the SBMT client know about this and gray out the correct parts of the menu, etc., you need to do a bit more: 4. In the directory /project/sbmt2/sbmt/data/accessControl are files accessGroupCollection.json userCollection.json These are also relatively clean and readable/editable. The userCollection.json file closely parallels the list of users in the apache .htpasswd-sbmt file and it's pretty intuitive. It must manually be kept in sync with the apache file. Only need to touch this when users change (added/removed). The accessGroupCollection.json file is correct and rational but not obvious how it works. For each access group it lists files that are restricted to that group. This includes not only directories/files for the models/images etc. but also metadata. So when there's a new version of the metadata file these blocks all have to be updated to include the new version numbers. More about that below. There's also a HUGE list of files/directories in the public group that are *NOT* restricted. This overrides the restrctions under each individual group as explained above. This is so that you can make parts of a model public and other parts restricted. Basically when there's a new metadata version, FIRST BACK UP THE FILE!!!! Then go through the file looking for the most recent metadata version number. Copy each block of lines, paste them in after the last set and replace the MD version in the copy. At the end of the block you copied from, you'll need to add a comma at the end to avoid messing up the JSON format. Then keep going, block by block by block until all of them are updated. For each new metadata version the file gets longer and longer. 5. On occasion, when changing model restrictions (say a new proprietary model or a current one that moved), need to edit the detailed content of one of the individual blocks, or add a new block for a new group. This can be tricky. Review models/directories that are set up similarly to the thing you are adding. Typically you have to add text in at least 4 places: a) the model/data directory block in the relevant group, e.g. add didymos/new-model to the DART group block; b) current version of the metadata directory to the group, e.g., add proprietary/allBodies-9.3/didymos/new-model to the DART group block; c) the model/data directory to the PowerUsers group block and d) current version of the metadata directory to the PowerUsers group. As always take care not to corrupt the JSON format, closing quotes, adding/removing commas etc. 6. VERY IMPORTANT: directory /project/sbmt2/sbmt/data/accessControl must have user/group/world read-and-execute permissions and all the JSON files must be user/group/world readable. This area is used by the server-side check for accessibility of all SBMT files that are managed by the file cache. If the permissions aren't right, PHP scripts fail and don't say why.