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  (Jan de Visser <jdevisser@digitalfairway.com>)
Re: Authentication trick  (Markus Schaber <schabi@logix-tt.com>)
Список 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 по дате отправления:

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: Authentication trick
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: XA end then join fix for WebLogic