ALUGL Librarian and Security stuff Hi. Been thinking over things and have some thoughts re Librarian & Security. Librarian =========== Who volunteers for this? The Librarian has to be present at all meets and must oversee all returns / loans, maintain the database, fixe occasional errors, chase people for overdues, carry out stocktakes – and bring the current ALUG stock with them to every meet in case a loan is wanted. May need a truck… I don’t like this – would you do it? – so I’ve been kicking around the idea of allowing casual person-person item passing. These need to be verified transactions on the database otherwise fraud is simple. The protocol I suggest below is – good enough?? Comments appreciated. What I’ve got is: Stock items are scattered i.e. held by who-ever-has-them-right-now. A potential borrower searches the library database and discovers Item X. They request Item X. The database sends an email to the current holder saying to bring Item X to the next meet. The database generates a random “release key” for the trade and emails it to the requestor. Eventually Item X and the release key change hands. The old holder enters the release key into the database and the transaction is verified. Kicker: Until the release key is in & verified the old holder is responsible for Item X; responsibility gets passed to the new borrower by entering the key. Further, requests for popular items can be stacked (that’s the idea behind having requests as transactions; these can be ordered by item / time sequence making a request stack – as well as other very useful life-history stuff). Is this adequate?? There is still a need for a librarian – but the job is much less onerous, for it frees them from compulsory attendance, involvement in every transaction & removes the “drag-the-stock-about” problem. Also, an item swap is not geographically limited to a meet – could be down a local pub etc. Again please kick holes in it people! Security =========== Other than people hacking in and diddling the transactions database, items database etc to generally kill the system there is a security issue over the names & addresses and account passwords. I want to encrypt the lot; ideally the entire database. And the transactions from server to client must be secure too otherwise login accounts get compromised. This is a job for an expert. I can get the database functional – but I would not put the system live in unencrypted form. Also does this complicate backup/restore/maintenance? Ill databases are tricky; an ill, encrypted database might be quite irrecoverable & un-de-encryptable. Security Expert Needed! Steve