licenssikring af access applikation

Hvad med password?

Skulle gerne være forskelligt fra kunde til kunde, men kun kræves i installationsøjeblikket.

Skulle gerne være forskelligt fra kunde til kunde, men kun kræves i installationsøjeblikket.

Skulle gerne være forskelligt fra kunde til kunde, men kun kræves i installationsøjeblikket.

Det er et meget stort område du bevæger dig ind på her.
Jeg har selv udviklet et system til mine applikationer hvor jeg har en licensfil med nogle koder i der bestemmer om en bruger/kunde har adgang til et givent modul.
Ideen er 'tyvstjålet' fra licensstyringen til Navision finanssystemet.
Jeg kan i sagens natur ikke vise dig min kode :-) men du kan godt få et eksempel på en licensfil.

; Licensfil til Vognmands IT
; HP Data © 2001 - 2008  Hugo Pedersen
; Licensfil genereret den 24-06-2008  18:47
; Af : HP Data - Setup creator version 8.26.02
; **********************************************************************
; Licensnummer  : HP-2006-TEST0001
; Program GUID  : 1654a877-3577-4897-8c03-6c8f748bb19d
; Licens GUID    : 3d7f5f15-e0a9-4f3b-007c-bd872f00fc36
; Crypto ID      : 0021281960
; Tilhører      : Demonstrations busserne
;                  Hans Christian Andersen
;                  12345678
;                  Algaden 198
;                  Vester Såby
;                  4250 Fuglebjerg
;
; Udløber        : 31-12-2010
;
; **********************************************************************
; Overtrædelse af programmets licensbestemmelser vil blive retsforfulgt !
; **********************************************************************
; Module ID        Module code
; **********************************************************************

  80001001      = 2EC44A32191B200C183FEFF0BA8AA2DC1FC7266823FA212F32D65B426D118919305C186D0BB7B22C
  80001002      = 814CCCA7557BDE01A36C342AA1D3B27C2BBA5B14E8BE6B2A9A0D968306C386FA6518BDE532C73B96
  80001003      = 7BBA833215B841368F222F62A6656A5F7A7F71DCAB37CCF4
  80001004      = E8998824B63321BEA9C17F6AD815CFEC75CDDC3002AFD261
  80001005      = 04374FCF374AD138E9CC8C903E99254B18B037A41CDFCAB4
  80001006      = E67F189539A03DB58773A392CDE52719B306C64BF7ECE46C0BE7E53FA7E209FC
  80001007      = 98A58BE206835FC58484DD7AF5C75732BA458546C1812D7D
  80001008      = B12DA2A98ADDFA465690F3DEACBF957147E0F117039EE6FF
  80001009      = 5D3D0E2DD98AAB6ACECAA3B661114E3C16574258FB954D5D
  80001010      = 428BA7E23916F255CD5EBD4F14D371B3F5B30838F356EB3C

  10000200      = 2FE4E1D9C2F3E1BD963177EC993372E5
  10000210      = 53229BCD296C6F4C6FD4B8A41C8E985A
  10000220      = D935BD0ECAEB7A139B23FB53B0327B4D
  10000230      = 98FA99EAEA87F1DBAD251D867E4902B0
  10000240      = FFD5078BA9E5F4528EF031FE188A3E7C
  10000401      = 132B8CA278D93F1F717E13829D14A529
  10000402      = 4A260B22C544E3B59B95CA660A670A8A
  10000403      = C5EC4D66BE871BCBFBFF87FDE14D5F86

  80003000      = 07C4AC04CD4F1D44A2C5041EC6AB1CC2D616ACE4B3CF13B8
  80003001      = 470E29B5FCCEEC17FF7A0ED9FC4CCE5D64E67933DC4D7854

  90704001      = 2E7C2BFFA7B8C8EDB0462CE855941C5A
  90704011      = 4A332ED66FD6CF1639881878EB50CBB9
  90704021      = 54C2677B5405E0EE79693926F3098C34
  90704031      = C9844E7E73694F6E81BCEBC93ABA88EA
  90704041      = 030E41F28FF239BDD32AB3DC619C72B6
  90704051      = EEDD36A629163D06F42E73345A1218DD
  90704061      = E87871755724849DAAD0C32B7C3B8187
  90704062      = D26D87AFA136D3D83918E1C82345CE82
  90704071      = C3A83EBCD24A5051806D9B5485C89737
  90704101      = 1E5840F29B697AC8453054D8CAAF3536
  90704901      = 6BEE558D22D09BB7D63F9F1072F52468

Tak for input, det løser ikke umiddelbart mit problem... Er det muligt at købe dit licenseringssystem ?

Det er desværre så proporitær og specialudviklet at det ikke egner sig til distribution.
Det var mere som input til hvordan det det kunne løses.

Der findes købesystemer til den slags også.

Hvor avanceret skal du bruge det? Har du mange kunder eller bare nogle få?
Jeg mener man kan komme langt med simple ting, hvis man få kunder og en simpel model.
Er det en engangslicens eller der noget med fornyelser for forskellige versioner?

Jeg har tidligere brugt at indsætte en stump kode der sletter de vigtigste formularer i databasen (men selvfølgelig ingen data).
På den måde bliver databasen ubrugelig.

Koden aktiveres efter en bestemt dato. Hvis der er betalt inden den dag fremsender jeg en ny frontend hvor kode er fjernet (eller udskudt 1 år, hvis det er en årlig licens).

På den måde er du sikker på at de betaler og hvis de ikke gør virker databasen ikke.

Det er klar de kan sætte uret tilbage på deres pc, men så skal de næsten have lov tænker jeg.

Tja,.

Det er et firma der på forskellige lokationer skal installere databasen, jeg ville gerne sikre at der blev betalt pr. installation. og sikre at det kun eer een installation pr. licens.

der bliver tale om omkring 10 lokationer med hver 3-5 installationer.

Jeg har ikke et skudsikkert forslag til dig, men jeg et lignende setup med 4 lokationer og ca. 20 pcere hvert sted. Fælles backend hvert sted.
Der betales bare per lokation og så kan de installere så tosset som de vil på forskellige pcer. Det forsimpler det noget.

Men jeg er tæt forhold til kunden (offentlig institution) og der er en del tillid, så jeg har ikke anstrengt mig for at få det mere sikkert. De er meget mere afhængige af at jeg fortsat vedligeholder databasen, end jeg er af betalingen.

Har du en installationsprocedure hvori du fx kan indlejre at der placeres en tekstfil et sted på pc'en - en form for cookie.
Eller sender du dem blot Access mdb-filen?

Det er blot to mdb filer. og jeg har kun telefonisk adgang til lokationen, hvilket betyder at jeg aldrig kommer til at se hvor mange installationer der er anvendt.

Jeg tænker om man kunne få access til at udlæse en maskinespecifik information Motherboard nr. eller lign, tilføje denne information til en tabel, som en gang om måneden blev sendt til mig, heri kunne jeg så se hvor mange forskellige computere der gennem den sidste måned havde anvendt systemet.

- kommentare ?

Jeg tror godt man kan generere en maskinekode fra hardwaresammensætning og evt kombineret med windowslogin eller noget sådant.
Men hvordan får det du sendt tilbage til dig igen?

Det bliver næste opgave.

første opgave er at få information der kan påvise antallet af installationer.

næste opgave bliver så at søge hvilke der bliver misbrugt, og så søge at lukke disse.

---- såfremt man kunne udlæse en maskinspecifik information, og sende den i en registrations e-mail til mig eller i en http-forespørgsel fra access, sammen med en installationslicensnøgle, så ville jeg kunne registrere antallet af maskiner en given installations nøgle var brugt.

Hvis dette tal overstiger 2 indenfor eksempelvis 3 måneder (såfremt en computer bliver skiftet). ville jeg vide at licensnøglen bliver misbrugt.

spørgsmålet er så hvordan access modtager informationen om at den er lovlig/ulovlig... og hvad jeg så skal gøre der...

- Som sagt er jeg åben overfor ideer.

Jeg mener man skal overveje hvor meget krudt man skal bruge på det med det installationsantal du har. Jeg ved jeg peger mod de lettere løsninger, men tid sparet på dette, er tid man kan bruge på applikationen. Hvad med en licens model, hvor de betaler per lokalisation?

Hvis du skal igang - ang. http-request. - hvad nu hvis de ikke har internet kan de så ikke bruge databasen?
Hvis de ikke tillader.

Ang. hvor mange der er logget ind: du kan have en formular med en timer, som periodisk tjekker hvor mange, der er logget ind i din backend (hvis du altså har en fælles backend)?
Hvis flere end x er logget ind skrives noget til en tabel/textfil/laves httprequest.
http://www.mvps.org/access/general/gen0034.htm
http://www.mvps.org/access/modules/mdl0055.htm
(brug også disse til at få maskinnavn).
eller den her http://www.mvps.org/access/api/api0009.htm

Eller skriv til den fælles backend når der logges ind og ud og styr dermed at f.eks kun 2 kan logges på af gangen og begræns dermed idéen med at lave flere installationer (for de kan så alligevel ikke logge på be-filen).


Læs evt i tillæg en værdi fra reg-databasen
http://www.mvps.org/access/api/api0015.htm
til at finde noget maskinspecifik information.

Spørgsmålet om brugerstyring er - som du ser - noget som optager mange, og som der er mange bud på en løsning af.

Jeg har en større database, som nu kører i 3. version. Det har givet mig lidt erfaringer med, hvad der virker:

1. version - udviklet i 1997 - var uden brugerstyring.
Resultatet var/er, at løsningen så vidt jeg ved stadig anvendes i den virksomhed den blev leveret til - og i 5-10 andre! (Min efterfølger i admin-jobbet havde ikke helt samme beskyttertrang overfor min kildekode, som jeg selv havde ;-))

2. version - fra 1999 - fik en relativt simpel styring, som låser både FE og BE, og har en liste med brugere med forskellige rettigheder. I BE er gemt et licensnummer, og hver gang databasen startes, foretages en beregning på nummeret. En del af beregningen giver en udløbsdato for licensnummeret, og er den overskredet beder databsen om et nyt nummer. Jeg bliver så kontaktet, og sætter mig med kuglerammen og beregner et nyt nummer med en given løbetid.
Dette gav styr på, at en given lokation havde ret til at bruge databasen. Men ikke hvor mange brugere, som kunne bruge den.
Og af praktiske hensyn (manuel beregning mv.) har licensnumrene ret lang løbetid - typisk et års tid. Hvilket giver problemer, hvis kunden f.eks. ikke betaler. Jeg er altså tvunget til at vælge mellem at holde hårdt på betaling før adgang - eller risikere at kunderne kan bruge databasen et år gratis.

I 3. version - fra 2005 - er licensnummeret flyttet fra databasen til brugeren. Samtidig har jeg lavet en mere kompleks beregning på nummeret, som bla. indregner brugernavnet. Jeg har også lavet en automatisk licensnummergenerator. Desuden har jeg lavet en funktion, som ved opstart forespørger på et ftp-sted, om der er en ny licensfil, og så selv opdaterer denne. Kun hvis der i en periode inden licensens udløb ikke har været webadgang, bliver brugeren besværet med en advarsel om licensens snarlige udløb.
Jeg har nu styr på, præcist hvilke brugere som er oprettet, og hvor lang tid de må bruge databasen. Kunden kan selv oprette brugere på forskellige niveauer, og har databasen internetadgang styres licenserne automatisk. Er der ikke adgang, skal brugeren inden første brug og ved licensudløb kontakte mig.
løsningen giver samtidig mulighed for at tilbagetrække retten til brug af databasen for en eller alle brugere (hvis databasen har internetadgang). Jeg lægger så blot en ny licensfil - som er udløbet - ud til brugeren.

Der er ikke meget egentligt svar i dette, men det giver forhåbentligt lidt inspiration.

For at hjælpe lidt, kan jeg "afsløre" ideen bag licensnummeret i 2. version: nummeret kan f.eks. være på 18 cifre. De første fire skal kunne deles med 6. De næste ti skal deles med 1432 og giver så udløbsdatoen i formatet ddmmåååå. Og endelig skal de sidste fire cifre være større en 8200.
Dette nummer er "simpelt" at generere og rimeligt kompliceret at aflure. forudsat naturligvis, at ingen kan se den kode som beregner det ;-)

Men det er der også råd for:
http://www.eksperten.dk/spm/175783

God fornøjelse ;-)

Tak Proc- Det er god inspiration især sammen med dit link.

Jeg kan især godt lide din ftp update funktionalitet. Kunne du afsløre koden til denne opdaterings funktionalitet? Især hvordan du ftp'er. har min interesse.

Venligst Leon

Jeg har tidligere lavet et ftp-modul der kunne kommunikere med en ftp-server.
Jeg fik meget inspiration fra denne artikel
http://www.databasejournal.com/features/msaccess/article.php/3513061/Simple-FTP-Methods-from-Microsoft-Access.htm

minieksempel: http://www.mvps.org/access/modules/mdl0015.htm

Men jeg mangler stadig at få det kodet ind i et class-module for at gøre det mere generelt anvendeligt. Den første artikel beskriver godt de fleste funktioner, man får brug for.