Thread: Authentication trick
Hi, some commercial softwares use a trick to avoid copy of a db, license-crack, etc. They use generate a key -> "ID of db-instance".For example, if you dump a db on other machine with postgres installed, this key will be different and so applicationwill not start. It was good for Oracle, DB2 and MS-SQL. Is there a "similar key" for Postgres? Is it possible retrieve it via-jdbc? How? Thanks, Giulio
antongiulio05@gmail.com wrote: > Hi, > > some commercial softwares use a trick to avoid copy of a db, license-crack, etc. They use generate a key -> "ID of db-instance".For example, if you dump a db on other machine with postgres installed, this key will be different and so applicationwill not start. PostgreSQL is not commercial, so there's no need for such artificial restrictions. There is, however, a unique system_identifier in pg_control file that's generated when initdb is run. It's used on WAL replay to check that the WAL logs were generated by the same installation. > It was good for Oracle, DB2 and MS-SQL. Is there a "similar key" for Postgres? Is it possible retrieve it via-jdbc? How? There's no way to retrieve system_identifier from the client. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
> > some commercial softwares use a trick to avoid copy of a db, license-crack, etc. They use generate a key -> "ID of db-instance".For example, if you dump a db on other machine with postgres installed, this key will be different and so applicationwill not start. > > PostgreSQL is not commercial, so there's no need for such artificial > restrictions. My application is commercial. It uses postgresql. I want include in my-app a "protection-trick" retrieving a some kind of"unique system_identifier". Your pg_control file could be good, but it's a "data-file". How can I extract infos from it? Around same dir I have found these infos: "myappdb" 20496 1663 3221455155 229682 Maybe are these the keys? Thanks, Giulio P.S.: sorry, now post became OT for "jdbc".
antongiulio05@gmail.com wrote: > My application is commercial. It uses postgresql. I want include in my-app a "protection-trick" retrieving a some kindof "unique system_identifier". Your pg_control file could be good, but it's a "data-file". How can I extract infos fromit? Sounds like a bad idea. system_identifier changes when you dump/restore to another installation. You don't want to forbid your users to restore from a backup, do you? > Around same dir I have found these infos: > > "myappdb" 20496 1663 3221455155 229682 > > Maybe are these the keys? pg_database? No, don't mess with that. And those numbers are not guaranteed to be unique across installations. 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
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
On Friday 01 December 2006 7:14 am, antongiulio05@gmail.com wrote: > 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 Good luck with that. Contacting *you* for permission to restore *my* data? you may want to reconsider that plan. jan -- -------------------------------------------------------------- Jan de Visser jdevisser@digitalfairway.com Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
> > 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 > > Good luck with that. Contacting *you* for permission to restore *my* data? you > may want to reconsider that plan. In software with license price many thousands of euros it's sad but frequent.
On Friday 01 December 2006 9:56 am, antongiulio05@gmail.com wrote: > > > 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 > > > > Good luck with that. Contacting *you* for permission to restore *my* > > data? you may want to reconsider that plan. > > In software with license price many thousands of euros it's sad but > frequent. Well, all I'm saying is that if I pay 'thousands of euros' I'd like to be treated with respect and trust, and not be at the whim of my supplier to allow me to restore my database. Oh yeah, you are going to respond to them on christmas day when their drive crashed and they urgently need to fall back on a backup, right? But it's your party :) jan -- -------------------------------------------------------------- Jan de Visser jdevisser@digitalfairway.com Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
Hi, Guilo, antongiulio05@gmail.com wrote: > 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. I hope that _no_ company will _ever_ run that software under that premise. Imagine a server crash, the admins set up the new server, and now they have to contact you to get the software running again. But you're on holidays, or your company went out of business, or your internet connection is broken, or snail mail needs 5 business days, or you simply tell them that they have to pay money now... Mission critial systems should _never_ be dependent on externals' good will. Your customer might get bancrupt because you're ill for a week. I hope that you're paying the insurance fee for this risk, to pay any liabilities. Thanks, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org