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 dont like this would you do it? so Ive 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 Ive 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 (thats 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