Adott egy kommercialis alkalmazas (es benne egy demon is), ami adatokat gyujt. Azt kellene megoldani, hogy #1 csak valid licence segitsegevel mukodjon a demon, ill. #2 havi aggregalt forgalmi adatokat fel lehessen tolni (sot, kotelezo legyen, mivel ez alapjan tortenne a szamlazas) egy tavoli billing szerverre.
Az #1-re az nulladikelso gondolat az volt, hogy egy jo serial key (amit a demon indulaskor ellenoriz) megoldja a dolgot, de a keygen.exe-k koraban gyorsan le is tettem rola. A kovetkezo otlet az, hogy a halozaton keresztul ellenorizzuk le (egy "licence szerverrel") a kapott serial key-t (ami szelsoseges esetben akar egy privat kulcs is lehet, vagy mas ugyfeladatokat is tartalmazo file), es ha koser, akkor ok, ha nem, akkor a demon sztrajkol.
De mi van akkor, ha a licence szerver atmenetileg nem elerheto? Az nem jo, ha a demon mindaddig sztrajkol, mert annak (normal esetben) 7x24-ben mennie kell, ill. az sem jo, ha minden adat beerkezesekor megkerdezi a tavoli licence szervert. OK, akkor adjunk egy kis turelmi idot a demonnak, es hadd fusson x ideig akkor is, ha a tavoli licence szerver nem tudja megerositeni a serial key validitasat.
A gondolat tovabbfejlesztese az, hogy legyen egy lokalis licence szerver, ami real time megmondja a demonnak, hogy minden ok, vagy sem. Es ez a lokalis licence szerver (annyira lokalis, hogy a 127.0.0.1-en futna) ellenorzi idonkent a serial key validitasat. A lokalis komponensnek alapvetoen az a celja (ld. #2 feladat), hogy mellekallasban elkuldje a havi szamlazasi adatokat egy SQL tablabol (view-bol) keszitett osszegzes utan.
A kerdes pedig az, hogy hol a hiba a fenti gondolatmenetben? ill. javasolj jobb megoldast.
Nehezites meg, hogy a licencet nem lehet egyszeruen IP-cimhez kotni, mert azt is tamogatni kell, ha az ugyfelnek akar tobb adatkozpontban is vannak szerverei (demon).
Egy ujabb nehezites (de ez opcionalis), hogy az lenne idealis, ha az alkalmazast, ill. a demont open source termekkent is lehetne terjeszteni.
Ha kell meg info, akkor mondok tobbet is.
- 6192 megtekintés
Hozzászólások
Milyen oprendszer?
---
#include "alairas.h"
- A hozzászóláshoz be kell jelentkezni
valamilyen linux, preferaltan debian 7.x vagy centos 6.x
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Én némileg kombináltam a fentieket.
Adott egy licensz szerver, ami privát felhő alapú, így nagyjából a 7*24 megoldott. Ezen felül adtam 30 nap türelmi időt. Installkor az adott telepítést kellett a rendszerben regisztrálni.
A licensz szerverem két modulos volt. Az egyik egy daemon ami unix socketen keresztül kommunikált a programmal, a másik pedig egy magam haxolta kernelmodul (a daemon ezt piszkálta), ami egy "védett tároló" és az tárolta a telepítéskor létrejött példány azonosítót (amihez az ügyfél kapott install kulcsot), a licensz szerverhez használt publikus kulcsot, stb.. Azért kernel modul, mert az meg tudja tagadni az illetéktelen hozzáférést a tárolóhoz. Nem tökéletes, de működött.
Installkor generálódott egy GUID ami a tárolóban lett eltárolva plusz megkapta a licensz szerver is. A daemon időnként megkérdezte a licensz szervert, hogy a nála lévő kulcs rendben van-e.
A licensz szerver adott egy "sót" amivel a daemon meghívta tárolót. Az visszaadott egy sózott hash-t, amit a daemon továbbított a licensz szervernek, aki megmondta, hogy rendben van-e.
Újratelepítéskor pedig az előző példány inaktív lett. Ezzel szűrhető volt a kiszivárgott kulcs.
A leírásom csak vázlatos, de nagyvonalakban így működött. :)
---
#include "alairas.h"
- A hozzászóláshoz be kell jelentkezni
jol hangzik, de nem akarok lemenni kernel szintre :-)
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Alapvetoen ezt ugy szokas megoldani, hogy a program 24 orankent egyszer bejelentkezik a license szerverre es az alapjan validal. Az Adobe CC egesz odaig megy, hogy 30 naponta egyszer kell bejelentkezned. Ehhez hozza kapcsolhatsz valami hardver komponents (pl. halozati szoftver eseten a halokartyak MAC addresse jellemzoen jo erre) es azzal aktivalsz.
Egyebkent en ugyfelkent nem szeretem, ha az elado ugy kezel mint egy potencialis tolvajt, plane ha mar egyszer megvette a szoftvert. Ilyen modon pl a PHPStorm (JetBrains) bekeri a licenszkulcsot es onnantol mukodik. Nincs licensing server, stb. Mukodik es ha kell tovabbi licenc, akkor veszunk meg egy kulcsot, ennyi.
- A hozzászóláshoz be kell jelentkezni
[deleted]
---
#include "alairas.h"
- A hozzászóláshoz be kell jelentkezni
A MAC address tipikusan nem jó erre, mivel változhat, a hálókártya cserélődhet, szkripttel felülírható.
Gyakrabban szokták alaplap GUID-hez kötni.
---
#include "alairas.h"
- A hozzászóláshoz be kell jelentkezni
Azt virtgepben hogy olvasod ki?
- A hozzászóláshoz be kell jelentkezni
Ugyanúgy, ahogy normál gépen. A virtuális gépnek is van egyedi azonosítója, ami a gép létrehozásakor generálódik. Virtuális gépen ezt adja vissza.
dmidecode | head -128
[...]
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Version: None
Serial Number: VMware-42 02 6e 82 f1 b3 60 89-d3 61 b8 9a d9 ed a8 28
UUID: 42026E82-F1B3-6089-D361-B89AD9EDA828
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
---
#include "alairas.h"
- A hozzászóláshoz be kell jelentkezni
vmx-ben atirhato:
uuid.bios = "56 4d 47 a1 07 ea 6f ab-59 e2 43 cb 91 9d 3d d7"
uuid.location = "56 4d 47 a1 07 ea 6f ab-59 e2 43 cb 91 9d 3d d7"
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
LXC guestben Ubuntu alatt nem megy a dmidecode per pillanat:
$ dmidecode
# dmidecode 2.11
/dev/mem: Operation not permitted
- A hozzászóláshoz be kell jelentkezni
Egyebkent en ugyfelkent nem szeretem, ha az elado ugy kezel mint egy potencialis tolvajt
valoban az (lenne) a legegyszerubb, ha xy kap egy serialt a vasarlas utan, aztan viszontlatasra. Amire azonban en gondoltam, az egy kisse mas jellegu felhasznalas: havidijas konstrukciorol van szo, aminek az alapja az adott honapban kiszolgalt userek vagy az atvitt GB-ok szama, etc.
Ha mondjuk $0.1 / user / hoval szamolunk, akkor nem mindegy, hogy 10 userrol jon a riport az adott honapban, vagy 10k userrol. Vagy hogy egyaltalan jon-e a riport, ill. az utalas.
Mondom, nem arrol van szo, hogy minden vevo tolvaj, hanem arrol, hogy levedjuk a seggunket, es a nem tervezett esetekre is van forgatokonyvunk. Ezert gondoltam arra, hogy a lokalis licenceszerver rendszeres idokozonkent elkuldi a riportot a nalunk levo szerverre, ill. adott esetben lehetoseget ad az adott licence lejaratasara is, ami utan az adobe cc peldaja alapjan meg mindig van 30 napja a vevonek az alkalmazas hasznalatara.
De ha erre a felhasznalasra van jobb, korrektebb otleted, szivesen veszem. HW-komponenssel nem akarom bonyolitani a dolgot, foleg hogy a MAC-cim tetszolegesre atirhato.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Szerintem ez a számlázás akkor működik, ha te hosztolod a szolgáltatást. Felhős, VM-es szolgáltatóknál pont ez van és teljesen korrekt. Kliens oldalra jobb az, ha egyszer adsz egy kulcsot, és csókolom. Bele lehet drótozni előre idő limitet, havi használati limitet, és ha túllépik, majd fizetnek újra jobb kulcsért. Amíg jó nekik az adott kulcs, addig nem kell foglalkozni velük. RSA kódolás kell a kulcsra, és akkor az feltörhetetlen lesz. Kevésbé valószínű, hogy az ügyfél nekiáll a binárist meghekkelni, főleg, ha vannak frissítések is néha. Ellenben kliens oldali számlázásnál feljön az a rengeteg probléma, hogy mi van, ha nincs kapcsolat, alapból tolvajnak van nézve az ember, és a hálózati kapcsolat plusz egy támadási felület az ügyeskedő ügyfeleknek is. Pl. két tök egyforma virtuális gépre felteszem a szoftvert (azonos UUID, MAC, stb., semmiből se tart), egyiket kicsit dolgoztatom, másikat nagyon, és megoldom, hogy csak az előbbi tudjon a számlázó szerverrel beszélgetni.
- A hozzászóláshoz be kell jelentkezni
Szerintem ez a számlázás akkor működik, ha te hosztolod a szolgáltatást.
ja :-) de en most csak a termeket akarom adni.
Bele lehet drótozni előre idő limitet, havi használati limitet,
igen, az is egy lehetoseg, hogy csinalok egy vevore szabott "vevo_id*havi_limit*bla-bla" adatot tartalmazo serial-t ill. egy publikus + privat kulcsot. A publikussal kodolom a serialt, majd atadom neki a privat kulcsot es a kodolt file-t. Ha a demon indulaskor kepes kiolvasni a serial-ban levo adatokat, akkor jo :-)
De en kifejezetten mas uzleti modellben gondolkozom, ami a hasznalattal aranyos. Ahhoz meg kell valamilyen hazatelefonalo feature.
Ha nincs kapcsolat, akkor nem tekintem tolvajnak a vevot, hanem x napig meg mukodik a demon (mert a lokalis licence szerver addig ok-t mond vissza). Azt meg nem mondtam, hogy a "nincs net" a vevo szempontjabol aligha jatszik, mert isp-kre celzom a termeket, itt max. az jatszik, hogy a nalam levo licence szerver elerhetetlen.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Én azt nem értem, hogy a daemon-nal egy host-on futó licenc szerver minek? Ha a daemon "törhető", akkor a mellette futó licenc szerver is...
Szerintem a licenc politikát kell átgondolni, esetleg egyeztetni a potenciális vevőkkel. Véleményem szerint nem jó az ilyen automata rendszer, mert ha a rá épülő szolgáltatás befut, vagy csak van egy pillanatnyi csúcsa, akkor Te nem vált mértékű számlát fogsz kiállítani az ügyfeled részére. A legtöbben ezért jobban szeretik (és a vállalati termékek licenc politikája is ilyen általában), hogy adott mennyiség van az árban, azt elérve vagy bővítik a licenc-et, vagy megelégszenek az adott limit adta lehetőségekkel. Mindenki a tervezhető költséget szereti.
Nem tudom milyen termékről van szó, de írsz user és forgalom alapján számlázást. A vevő felé mi garantálja, hogy Te nem generálsz forgalmat? Ha nem úgy szól a licenc, hogy X pénzért X user és/vagy X pénzért Y forgalom, akkor Te érdekelt vagy a user szám és forgalom (akár mesterséges) feltornászásában, tehát az ügyfelet károsító visszaélésre ad okot/lehetőséget a licenc rendszered. Így kétélű lesz a fegyver, mert Te félsz, hogy az ügyfél nem fizet a valós adatok alapján, az ügyfél pedig fél, hogy az adatok nem valósak, hanem mesterségesek.
- A hozzászóláshoz be kell jelentkezni
A termek egy spec. mail szerver (ez a demon), amire en jo kozelitessel nem tudok forgalmat generalni, ill. en nem vagyok user azon a gepen, hogy tobb user utan kelljen fizetni. A szamlazas alapja egy adatbazis tabla, amelybe minden email utan kerul egy rekord. Ezt ugyan megpiszkalhatja a vevo, de ez a bizonyos tabla letfontossagu a rendszer mukodesebe, tehat kontraproduktiv a matatasa.
Az X user vagy Y forgalom is lehet egy jarhato ut, de ha vesz valaki 10k usert, akkor boldog lesz, ha valojaban csak 7k usere van? Vagy mi lesz akkor, ha az adott honap 25-en mar felhasznalta az adott forgalmi limitet? Ha a vevonek csak 200 usere van, akkor csak 200 utan kell fizetni, de ha 10k usere van (akik fizetnek neki), akkor nem gondolom, hogy faj neki, ha o is 20k user utan fizet.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
A megbízhatóságról/szavahihetőségről volt szó. Én azért írtam a plusz user-t, plusz forgalmat - ugyanis ha ezeken nincs kontroll (szabadon nőhet, majd a vevő kifizeti hó végén), akkor Neked érdekedben áll a saját gyártású rendszert kijátszani, hogy többet mérjen, így többet számlázz. De az első bekezdéses állításra a vevőd azt mondhatja, hogy Ő pedig nem programozó, nem tudja meghekkelni a rendszered, hogy csaljon, ezt fogadd el tényként. Egyik állítást sem lehet könnyen bizonyítani a partner felé. Ezért olyan szisztéma kell, ami mind a két fél érdekeit védi.
Ráadásul ha levelező rendszerről van szó, ott pont nem hallottam még dinamikus, használat-függő számlázásról. Szóval a szerver szoftvert X felhasználóra veszi meg a szolgáltató, és az vagy sok, vagy elég, vagy kevés lesz idővel. Ennek arányába változtatják a licenc mennyiséget. Az a gyártó dolga, hogy olyan egységekben adja a licenc-et, ami fedi a vevők vásárlási igényeit, és olyan sűrűn lehessen a mennyiségen változtatni, ami mind a két félnél még elfogadható. De az adott időszakra előre megállapított mennyiség és ár vonatkozzon, és ez csak mindkét fél tudtával változzon (ne a hó végi meglepi számlából derüljön ki, mennyi is volt valójában a felhasználószám).
A forgalmi limitet pedig nem igazán tudom értelmezni egy ilyen funkciót ellátó rendszer esetén, mert a mai világban nem tudom magam elé képzelni, hogy a szolgáltató hogyan fizetteti ki a saját e-mail felhasználójával azt, hogy milyen terjedelmű volt az e-mail kommunikációja. Forgalmi limit csak nagyon drágán üzemeltethető hálózatoknál szokott csak lenni manapság. Esetleg akkor van forgalom számlálásnak értelme, ha Te magad nyújtod a szolgáltatást, és az infrastruktúra után forgalom arányosan fizetsz Te magad is.
Szoftver oldalán a saját problémádat, név szerint a forgalom pontos, módosíthatatlan dokumentálását megoldhatnád úgy, hogy az ominózus táblát checksum-ozod (a forgalomtól/terheléstől függő gyakorisággal), ezt a checksum-ot valami kulccsal titkosítva tárolod a DB-ben (meg mellé az infót, hogy mely tábla-tartományra vonatkozik). Utána csak le(/fel)töltöd a DB-t, és a kulcsod saját példányával megnézed, hogy a tárolt kulcs egyezik-e a frissen számítottal. Ez akár számlázási időszakon belül többször is lehet: a daemon számol egyet, ezt elküldi Neked a tárolt-titkosított verzióval együtt, te pedig visszajelzel, hogy működjön-e tovább, vagy álljon le mert tampered a DB.
Sőt, ha van egy ilyen kulcspár a vevődnek is, akkor Neki is lehet egy saját checksum példánya és saját ellenőrzése. Így Ő is megbizonyosodhat, hogy Te (azaz a szoftvered) sem manipuláltad a táblában lévő adatokat.
- A hozzászóláshoz be kell jelentkezni
-1
A világ egyre inkább a pay as you go fizetés, és a lehető legkisebb egységekben számolás felé tolódik. Mobilnál perc alapú számolás helyett másodperc alapú. VPS bérlésnél havi helyett másodperc alapú. Hírlevélküldő cuccnál fix havidíj helyett minden ezer elküldött email után. És még sorolhatnám...
- A hozzászóláshoz be kell jelentkezni
+1 a pay as you go modellre, noha nyilvan lehet olyan eset, amikor jobb a "korlatlan" csomag.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Persze, általában valami hibrid megoldás van. Pay-as-you-go és egy unmetered jó drágán (de olcsóbban, mint végtelen*egységár)
- A hozzászóláshoz be kell jelentkezni
A megbízhatóságról/szavahihetőségről volt szó.
A szamlazas alapja egy sql tabla, es a billing infok is egy masik tablaba kerulnenek. A checksum a tablara (sorokra) jo otlet. Ha pedig a kedves ugyfel nem programozo, igy ab ovo nem tudja meghekkelni a rendszert, akkor fogadja el o is az en ertekemet.
A trukkozest ugy is ki lehetne szurni, hogy a billing infokat a demon (vagy a licence szerver) nem havi 1x tolna fel, hanem surubben, pl. naponta, vagy akar orankent is. Igy ha hirtelen az derul ki, hogy ho 16-ig 2348 user hasznalta a rendszert, de ho 23-an nezve mar csak 145, akkor nyilvan bibi van, amit jelezni lehet a vasarlo fele. Btw. hogy ne hirtelen deruljon ki, lenne egy accounting/billing oldal, ahol a vevo kb. real time megnezheti, hogy hol tart.
A forgalom alapu szamlazas csak egy otlet volt, amugy letezik ilyen modon szamlazo szoftver. Van pl. egy kereskedelmi antivirus/antispam termek, amelynek a licenceben konkretan benne van, hogy havonta x GB mail forgalomra/ig. Bar van(?) hozza korlatlan licence is.
A feloldhatatlan problemas esetre az lenne a solution (a termek licence leirasaban is leirva), hogy a termek onnantol kezdve meg 30 napig hasznalhato. Aztan a vevo majd nez egy masik megoldas utan.
Nezek majd 1-2 konkurens termeket, hogy naluk hogy es mint van, aztan leirom nektek ide.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Egyreszt igazad van, masreszt nem. Ha valamit szolgaltataskent adsz el, akkor jo a pay as you go. Aztan persze van olyan, hogy X edition havi Y mennyisegig tud, azutan upgradelsz. Viszont vegeredmenyben arrol szol a story, hogy az alkalmazasod megtakarit-e annyi penzt az ugyfelnek, hogy boldogan faradjon a kasszahoz vagy nem. Mert ha nem, akkor ugyis mindegy, ha meg igen, akkor egy komoly ceg nem fog azzal szorakozni, hogy meghackelje a szamlazast. Egesz egyszeruen azert, mert nem eri meg, a jogi kovetkezmenyek miatt sem, a belefektetett emberi eroforras miatt sem es nem utolso sorban a potencialis support issue-k miatt sem. Gondolj bele: ha lebukik, onnantol nem adsz hozza supportot. Ez sokkal nagyobb veszteseg neki, mint az a megtakaritott X osszeg havonta.
- A hozzászóláshoz be kell jelentkezni
a mailarchiva multitenant verzioja (amivel isp-kre lonek) per user, per honap alapon szamlaz, pedig nem szolgaltatas, hanem termek:
"includes an automated billing component that makes it easy to bill customers. The billing model works on a per mailbox per month basis."
A sima enterprise verzional pedig egyszeri dij van, ami szinten mailbox alapon szamitodik (+kotelezo min. 1 eves support dij, ami szinten fugg a mailbox-ok szamatol).
akkor egy komoly ceg nem fog azzal szorakozni, hogy meghackelje a szamlazast.
egyetertek, de megsem mennek el egeszen addig a gentlemen's agreement-ben addig, hogy bemondasra elhiszem, amit xy mond. Szoval, ha vegul az x useres licence lesz a befuto, abban az esetben sem tartom az ordogtol valonak a sajat billing szerverre torteno szamlazas infok feltolasat. Ebben az esetben azt mondja a vevo, hogy kell nekem 2500 useres licence, de a termek nem korlatoz le, ha mondjuk megis 3500 user fogja hasznalni, hanem majd en latom ezt a szamot a hozzam kuldott adatok kozott, aztan kapnak egy ajanlatot egy nagyobb licencere.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Pedig a Microsoft sok esetben ezt csinalja pl. a CAL-okkal vagy hogy a banatba hivjak. En annyit csinalnek, hogy csinalnek egy RSA-kodolt licenckulcsot amit a szoftver dekodol es abban legyen benne, mire jogosult. Ha vesz nagyobbat, kap uj licenckulcsot, meghatarozott idore, mondjuk 3 havonta cserelodik. Opcionalisan automatikusan. De nagyon nem izgulnam tul a vedelmet, ha meghackelik, meghackelik, viszont onnantol ha kiderul, ugrott a support, illetve eletbe lep a "breach of contract" resz a ToS-bol.
- A hozzászóláshoz be kell jelentkezni
ok, akkor mit szolsz ahhoz, mint fiktiv vevo :-), hogy kapsz egy x idore (pl. 1 v. 3 honap) ervenyes licence kulcsot, ami onmagaban eleg, es a mukodeshez nem kell hazatelefonalni a demonnak, indulaskor el tudja donteni, hogy valid-e a licence vagy sem. (Bar ugye mi van, ha valaki jatszik az oraval? Ezt aligha lehet maskent kivedeni, minthogy indulaskor egyeztetni kell egy tavoli geppel)
viszont onnantol ha kiderul, ugrott a support, illetve eletbe lep a "breach of contract" resz a ToS-bol.
na igen, de ez csak ugy derul ki, ha ezek a billing infok rendszeresen mennek a nalam levo licence/billing szerverre (aminek szinten benne kell lennie a ToS-ban, es ha nem akarnak jonni ezek az adatok, akkor az mar szerzodesszeges). Remelem, ez meg nem a fiktiv ugyfel tolvajnak nezese :-)
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Aki egy mailszerveren orat allit egy ilyen miatt az nagy barom. Plane, hogy ha barmifele mail szurest csinalsz, akkor a jovoben levo leveldatumok miatt eleve gyanus lehet a dolog. Mint fiktiv vevo egyebkent nem szeretem az olyan cuccokat amik a halozatombol szamomra ellenorizhetetlen adatokat kuldozgetnek kifele, plane nem titkositva. De lehet hogy nem en vagyok a celkozonseg.
- A hozzászóláshoz be kell jelentkezni
Rakerdeztem xy termeknel, hogy miert csinalnak hazatelefonalast. A valaszban azt irtak, hogy (es emlekeztetoul: az xy termek celkozonsege az isp-k) azert, mert a hasznalt mailboxok (szama) alapjan tortenik az isp fele a havi szamlazas. A termek pedig perodikusan riportolja a mailbox hasznalatot az o licence szerveruk fele. Meg azt is hozzatettek, hogy az adataid teljes biztonsagban vannak, mert ez a kommunikacio csak licenceles celokra van hasznalva.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Right. Es az elmult jopar ev hasonlo mondatai utan kovetkezo adatkezelesi botranyok senkiben nem ebresztik fel a kisordogot... ok, mondom, nem vagyok valszeg celkozonseg.
- A hozzászóláshoz be kell jelentkezni
Kérdés, hogy a biztosnágosan alatt mit értesz?
Amint más gépére teszel egy alkalmazást, onnantól csak rajta múlik, hogy feléd mit kommunikál. A csalás lehetőségét kizárni nem tudod, csak nehezíteni...
Egy adott gép 'fizikai' paraméteréhez kötni a licencet viszont szerintem eléggé elavult dolog.
Licencként én inkább SSL tanúsítványokat használnék, úgy hogy egyedileg minden ügyfélnek saját tanúsítványt fordítanék bele az alkalmazásába. Így:
- Te egy standard PKI rendszerrel meg tudod oldani a licencek érvényességének kezelését.
- az alkalamzás titkosítottan tud forgalmi adatokat küldeni és/vagy becsekkolni hozzád licenc ellenőrzés céljából (ha pedig nem jelentkezik be és/vagy nem küld x naponta adatot, letiltod a működését)
Ilyesmit használnak régóta netes játékokban is, hogy ne lehessen könnyedén lokáisl hackolásokat alkalmazni...
*** Ha a tanúsítványt, és a titkosítás nem fordítod bele az alkalmazésba, akkor könnyedén ki lehet játszani a licenc korlátozásokat.
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
Ez vicces. Valami ilyesmi (nem pont ez) jutott eszembe, de nem mertem leírni, mert tartottam tőle, hogy egy egyébként triviális lyukat nem veszek észre az elméletben. :)
upd: miután szakértő úr leírta pontosabban is, hogy mit akart, már tárgytalan, csak az utókor számára...
Én úgy képzeltem volna, hogy mondjuk gpg/pgp beépítve egy loaderbe, minden vásárló saját image-et kap. Az image-hez tartozik egy kulcspár, aminek a privát fele az eladónál, a publikus fele a vásárlónál van. A vevő egy a privát kulccsal lekódolt binárist kap, amit a loader a publikus kulcs segítségével csomagol ki a memóriába és onnan futtat.
Ez azt hiszem, a keygen.exe-k ellen megfelelő védelem.
Az egy más téma, hogy ha nem r=1 userről van szó, akkor viszonylag könnyen törhető a védelem. Viszont a később felvázolt feladatra az ilyen védelem már nem jó.
A hardverhez kapcsolódó védelmeket kifejezetten utálom.
Nem csak azért, mert eleve az a látszat, hogy potenciális tolvajként kezelik a vásárlót, hanem azért is, mert anno volt szerencsém ilyen licencek miatt szopni, mint a torkosborz, amikor a bedöglött vas helyére be kellett tolni valami mást.
- A hozzászóláshoz be kell jelentkezni
Ez sem rossz, sőt manuálisan kezelhető példányszámban el tudom képzelni.
A netes játékoknál akkor ha jól értem van buildszerver, ami mindenkinek egyedileg forgatja az alkalmazást?
---
#include "alairas.h"
- A hozzászóláshoz be kell jelentkezni
A netes játékban nincs konkrét egyedi beépített tanúsítvány, de ott minden esetben be kell jelentkezni (jelszóval, tokennel) és az képezi a titkosítás és/vagy azonosítás/licenc csekkolás alapját...
Ezesetben a tanúsítványt fordított irányba használják, hogy ne lehessen 'tört szerverre' csatlakozni vele ;)
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
Kérdés, hogy a biztosnágosan alatt mit értesz?
nyilvanvalo, hogy aki rev. engineering-gel nekiesik, az egy ido utan kedvere gyurmazhat az alkalmazassal. Nem ez ellen akarok vedekezni (ennyi energiat nem tudok belefeccolni a dologba), hanem arra gondoltam, hogy az alkalmazas megpiszkalasa nelkul ne lehessen modositani a riportolt adatokat.
Amint más gépére teszel egy alkalmazást, onnantól csak rajta múlik, hogy feléd mit kommunikál. A csalás lehetőségét kizárni nem tudod, csak nehezíteni...
a nehezites eleg. Ha jol ertem a koncepciodat, akkor ebben az esetben is kell egy helyi licence szerver.
Licencként én inkább SSL tanúsítványokat használnék, úgy hogy egyedileg minden ügyfélnek saját tanúsítványt fordítanék bele az alkalmazásába. Így:
hmm, ez tetszik. Ezek szerint a licence/tanusitvany egy string a binaris programban? Ill. jol ertem, hogy a hasznalt openssl lib-et statikusan kell linkelni a demonhoz? Azt vagom, hogy gyerekjatek a programnak egy barkacsolt libssl.so-t adni, ami mindenre OK-t mond, de kb. erre mondom, hogy ilyen szinten azert nem gondolom tolvajnak a vevoket, ill. ennek azert a vevo szamara is van hatranya.
Ha a tanúsítványt, és a titkosítás nem fordítod bele az alkalmazésba, akkor könnyedén ki lehet játszani a licenc korlátozásokat.
arra gondoltam, hogy en generalok egy kulcspart, amibol a privatot megkapja a vevo, es en meg a publikussal (ami nalam marad) ellenorzom/dekodolom az adatokat.
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
"hanem arra gondoltam, hogy az alkalmazas megpiszkalasa nelkul ne lehessen modositani a riportolt adatokat"
Ha ennyi alég, akkor használhatsz szabványos már meglévő modulokat/libeket a titkosítás és az certificate alapú azonosításhoz (licenceléshez)
Erről bővebben:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Certificate_…
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
public-privat kulcsokat forditva hasznald! nalad van a privat, es a vevo kapja a publicot. pl a license fajl egy txt, benne hogy valid x-tol y-ideig, ennyi user, annyi forgalom, vegen meg egy signature. azt tudja ellenorizni a pubkey-el. meg mindig bekuldott adatot titkosit a pubkey-el, es csak te tudod kibontani.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
igazad van, forditva irtam a privat - publikus kulcs szerepet, kossz a patch-et :-)
--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)
- A hozzászóláshoz be kell jelentkezni
Én értem, h mit szeretnél és azt gondolom, hogy nemjó felől közelítitek meg a problémát. Hogy miért, azt még nem tudom :)
- A hozzászóláshoz be kell jelentkezni