Re: Authentication trick

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

In response to

Responses

Browse pgsql-jdbc by date

  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