Re: Authentication trick
От | antongiulio05@gmail.com |
---|---|
Тема | Re: Authentication trick |
Дата | |
Msg-id | 20061201131429.87e1956f.www.gmail.com@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: Authentication trick ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Ответы |
Re: Authentication trick
Re: Authentication trick |
Список | pgsql-jdbc |
Hi Heikki > You don't want to forbid your users to restore from a backup, do you? Yes I want! This is a (painful) trick:) I want to avoid not authorized dump/restore in other machines (a single customer pays for remote upgrading of his db-infos). If you want dump/restore backup you will contact me - I'll enable new user-authentication based on new "unique-key-from-db"but will disable old key. You pay for one db not 2,3,..... one db:one license Obviously this is a real pain the ass for restore (but we are thinking to authomatize it with: unlock-new-key/lock-old-key). Problem now is how to retrieve this unique-key:) > I'd recommend trusting your users instead of adding limitations like > that. They can be a real pain the ass if you're user wants to move his > database to another server, run a warm-standby, backup/restore, run in a > virtualized environment etc. and you don't want to cause hardship like > that to your customers, do you? > > If you still want to add a server key etc, I'd suggest creating user > defined function that extracts a system identifier from somewhere else > than the database. Thanks, Giulio
В списке pgsql-jdbc по дате отправления: