Entitlement-ak mugikorretako aplikazioetan: zergatik baimena zerbitzarian kudeatzeak sarbide-arazoak ekiditen dituen
Erosketa-katalogoa eta atzipen-baimenak bereizteak diru-sarrerak babesten ditu manipulazio lokaletatik eta kontu bakoitzaren egoera erreala sinkronizatzen du edozein plataformatan.
Mugikorretarako softwarea garatzean ohiko akats bat egin ohi da: produktu bat erostea eta gailuaren barruan sarbidea zuzenean ematea baliokidetzat jotzea. Erabiltzaile batek App Store edo Google Play bidez ordainketa bat burutzen duenean, aplikazioak baieztapen lokal bat jasotzen du. Haatik, telefonoak berak seinale hori interpretatuko duela eta funtzio aurreratuak desblokeatuko dituela uste izateak arkitektura ahul eta mantentzen gaitza sortzen du.
Desakoplamendu tekniko hori konpontzeko entitlement kontzeptua (edo atzipen-eskubidea) erabiltzen da. Geruza abstraktu honek definitzen du zein funtzio, eduki edo zerbitzu-maila dagozkion erabiltzaile bati une jakin batean, ordainketa nola edo non egin den kontuan hartu gabe.
Zer diferentzia dago produktu baten eta entitlement baten artean
Produktu edo SKU batek denda bateko katalogoan dagoen elementu komertzial zehatz bat adierazten du: hileko harpidetza estandar bat, beheratutako urteko plan bat edo kreditu-pakete bat. Mugikor-plataforma bakoitzak kobrantza horietarako identifikatzaile independenteak konfiguratzea eskatzen du.
Aitzitik, entitlement batek aplikazioaren barruko baimen funtzionala ordezkatzen du. Adibidez, erabiltzaile batek `pro_sarbidea` eskubidea izan dezake. Eskubide ber horretara bide anitzetatik irits daiteke:
- iOSetik kontratatutako hileko harpidetza bat, pagos en apps ereduaren barruan.
- Androiden erositako urteko plan bat, aldi baterako promozio batekin.
- Kreditu-txartel bidez webgunean ordainketa-pasabide tradizional baten bidez prozesatutako ordainketa korporatibo bat.
- Euskarri teknikoko lantaldeak eskuz egindako esleipen bat.
Aplikazioaren logikak zuzenean `com.enpresa.app.hilekoa_ios` bezalako produktu-identifikatzaile lokalak egiaztatzen baditu, katalogoan egindako edozein aldaketaren ondorioz aplikazioaren kodea eguneratu eta dendetan bertsio berriak argitaratu behar dira. Logika hori entitlement-etara eramanez gero, aplikazioak soilik galdetzen du erabiltzaileak `pro_sarbidea` aktibo duen ala ez, eta backend-aren esku uzten du ordainketen eta baimenen arteko lotura.
Baimenak mugikorrean kontrolatzearen arriskuak
Eskubideen egiaztapena bezeroaren gailuan uzteak arrisku tekniko eta komertzial handiak sortzen ditu seguridad arloan:
- Manipulazio bitarra eta kode-injekzioa: Administratzaile-baimenak aldatuta dituzten gailuetan (jailbreak edo root), tresna dinamikoek erantzun boolear lokalak atzematea ahalbidetzen dute, aplikazioari baliozko erosketa bat balego bezala jokatzeko aginduz.
- Errepikapen-erasoak eta ordainagiri faltsuak: Aplikazioak erosketa-agiria lokalean zuzenean irakurtzen badu, Apple edo Googleren interfazeekin gako pribatuen bidez alderatu gabe, erasotzaile batek beste kontu batzuetako agiri legitimoak berrerabil ditzake edo sinadura simulatuak sor ditzake.
- Plataforma anitzeko sinkronizazio-falta: Egoera mugikorrean soilik gordetzen bada, tabletan ordaintzen duen erabiltzaile batek ez du berehalako sarbiderik izango ez telefonoan ez web-nabigatzailean, eta horrek marruskadura eta laguntza-eskaera alferrikakoak sortzen ditu.
Entitlement-a zerbitzarian zentralizatzeak bezero mugikorra aurkezpen-terminal huts bihurtzen du. Aplikazioak ez du pantaila bat ireki ala itxi erabakitzen; autentifikatutako erabiltzailearen profila bere datu-basean kontsultatzera mugatzen da.
Zerbitzaritik zerbitzarirako baliozkotzea eta gertaerak denbora errealean
Entitlement bat fidagarria izan dadin, zerbitzariak kanal seguru eta egiaztatu baten bidez jaso behar du dendaren baieztapena. Fluxu tekniko estandarrak urrats hauek jarraitzen ditu:
1. Gailuak transakzioa abiarazi eta prozesatzen du aplikazio-dendaren pasabidean.
2. Transakzio-identifikatzailea edo sinatutako token kriptografikoa jasotzean, bezeroak ez du zerbitzua desblokeatzen; berehala bidaltzen du zerbitzariaren APIra.
3. Zerbitzaria Appleren (StoreKit 2) edo Googleren (Google Play Developer API) API ofizialekin komunikatzen da kobrantzaren benetakotasuna egiaztatzeko eta jatorrizko transakzio-identifikatzailea erabiltzailearen barne-identifikatzailearekin lotzeko.
4. Zerbitzariak bere datu-baseko entitlement-en taula eguneratzen du eta gailu mugikorrari finkatutako egoera berria itzultzen dio.
Behin hasierako eskubidea ezarrita, suscripciones direlakoen bizi-zikloaren mantentzea zerbitzaritik zerbitzarirako jakinarazpen zuzenen bidez kudeatzen da (Server-to-Server Notifications edo RTDN). Kobrantza errepikakor batek huts egiten duenean, grazia-aldian sartzen denean edo baliogabetzen denean, dendak zuzenean jakinarazten dio backend-ari, eta hark denbora errealean doitzen edo ezeztatzen du entitlement-a, erabiltzaileak aplikazioa ireki beharrik izan gabe.
Ondorio praktikoa
Terminal mugikorra, definizioz, ingurune ez-fidagarria da, eta garatzaileak ez du bertan erabateko kontrolik. Baimen-logika gailuan bertan produktu zehatzei lotuta mantentzeak katalogo komertziala zailtzen du eta negozioa manipulazio lokalaren bidezko iruzurraren mende jartzen du.
Dendek transakzioak zerbitzari zentralizatu bati jakinarazteko arkitektura bat ezartzeak —zerbitzariak berak bezero bakoitzari dagozkion entitlement-ak kalkulatu eta zerbitza ditzan— aplikazioaren bertsio finkoekiko mendekotasuna murrizten du, webgunearen eta mugikorraren arteko bateratzea errazten du, eta erabiltzaile bakoitzak ordaindu duen zerbitzua zehaztasunez jasoko duela bermatzen du.
Harpidetzak muntatzen ari zara?
Begiratu tarifak eta probatu panela adibide-datuekin ezer integratu aurretik.