From: | "antongiulio05(at)gmail(dot)com" <antongiulio05(at)gmail(dot)com> |
---|---|
To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
Cc: | <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Authentication trick |
Date: | 2006-12-01 12:14:29 |
Message-ID: | 20061201131429.87e1956f.www.gmail.com@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2006-12-01 12:28:29 | Re: XA end then join fix for WebLogic |
Previous Message | Tore Halset | 2006-12-01 11:33:44 | setBlob/getBlob, slony and bytea |