iOS VPN profila: passwordReference, ez pasahitza

Profil bat instalatzen duzu, tunela altxatzen da eta dena amaituta dirudi. Ondoren telefonoa berrabiarazten da, on-demand-ek konexioa esnatzen du aplikaziorik aurreko planoan gabe, eta tunelek ez du abiarazi nahi. Profila oraindik han dago eta pasahitza oraindik zuzena da, eta horregatik hutsegite honek jendea toki okerrean bilatzera bidaltzen du. Network Extension batek ezin du zure sekretua profiletik irakurri: bere kabuz ebatzi dezakeen giltza-sarrerako erreferentzia bat behar du.

Beheko bideak zeharkaldi horretan zehar konexio-saiakera bat jarraitzen du, erreferentzia eraikitzen duen kontsultatik hura probatzen duen berrabiaraztera arte.

Profila heldulekua gordetzen du, ez sekretua

NEVPNProtocol-ek passwordReference eta sharedSecretReference agerian uzten ditu arrazoi batengatik. Daemon-ak tunel bat abiarazten duenean agian ez da zure prozesuaren barruan exekutatzen, beraz ezin du zure kodea deitu eta pasahitzik eskatu. Giltza-sarrerako erreferentzia iraunkor bat irakurtzen du, bere testuinguruan ebazten du eta elementua bera eskuratzen du.

Erreferentzia hori giltza-sarrerari eskatuta eraikitzen duzu, datuak eskatzea baino eskaera desberdina dena:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

Emaitza den objektua protokoloari eman, ez elementuaren datuak. Praktikan profilek sekretua non bizi den erregistratzen du, eta horregatik konfigurazioaren segurtasun-kopia batek ez du pasahitza isilka plist batean bikoizten.

Zergatik erantzuten du APIak -50

errSecParam-ek esan nahi du eskaera edo balioa gaizki osatuta zeudela eragiketarako, eta erreferentzia- eta datu-eskaerak nahasten direnean gehien ikusten den errorea da. Datuak eskatzea kodea hartzaileak erreferentzia bat espero duen bitartean, byte gordinak passwordReference-ri esleitzea edo aplikazioak erabili ezin duen sarbide-talde batekin kontsultatzea, denek sortzen dute.

Bilgarri diren liburutegiek horretara gonbidatzen dute. Byteak itzultzen dituen laguntzailea ez da erreferentzia bat itzultzen duenarekin trukagarria, beraz konponketa normalean beste kontsulta bat izaten da, ez beste pasahitz bat.

Desadostasun berak azaltzen du kexarik gabe gordetzen den eta gero konektatzen ez duen profila: gordetakoa blob bat da, ez helduleku bat, eta daemon-ak ez du ezer ebazteko.

Ondo gordetzen da, konektatzean huts egiten du

Gordetzeak zure aplikazioaren testuingurua erabiltzen du. Konektatzeak daemon-arena, eta biek ez dute sarbide bera. Beraz, profil batek simuladorean egiten dituzun proba guztiak gainditu eta lehen on-demand abiaraztean huts egin dezake.

Hori da berrabiaraztearen sintomaren forma ere: aplikazioa irekita dagoen bitartean funtzionatzen du eta sisteman tunelela berak abiarazten duenean hiltzen da.

Probatu atzeko planoko bidea nahita bidali aurretik. Eragin on-demand konexio bat aplikazioa itxita, eta gero irakurri gailuaren kontsola, ez aplikazioaren egunkaria, hutsegitea erreferentzia ebatzi nahi izan zuen prozesuak erregistratzen duelako. Kontsolak daemon-ak elementua ukatzen duela erakusten badu, erreferentzia ondo dago eta arazoa elementuaren irisgarritasuna da.

Irisgarritasunak erabakitzen du berrabiarazteak funtzionatzen duen

Elementua tunelela abiarazten duen sistema-prozesuarentzat irakurgarria izan behar da, eta hori zure aplikazioa aurreko planoan dagoeneko baino audientzia zabalagoa da. Muga horrek irisgarritasun-atributua aukeratzen du zuretzat. Lehen desblokeatzera arte babestutako elementu bat eskuragarri dago atzeko planoko abiarazte baterako gailua behin desblokeatu ondoren; gailua oraintxe desblokeatuta egotea eskatzen duen elementua ez dago.

Klaserik zorrotzena aukeratzea tentagarria da eta horixe da on-demand profila telefono blokeatuan hausten duena.

Klasea aldatu ondoren, sortu berriro elementua lehendik dagoenaren atributuak editatu beharrean, eta gero gorde berriro protokoloa erreferentzia berri batekin. Lehendik dagoen elementu bateko atributu-aldaketek ez dute beti dokumentazioak iradokitzen duen portaera sortzen, eta berreraikitako elementu batek zalantza kentzen du.

Biraketa gordetako profilak usteltzen diren tokia da

Giltza-sarreran pasahitza aldatzeak ez du automatikoki aldatzen gordetako profilak seinalatzen duena. Elementua ezabatzea okerragoa da: profilek jada existitzen ez den zerbaiti erreferentzia eusten dio, eta hutsegiteak autentifikazio-ukapen itxura du.

Biratu ordena bakarrean. Eguneratu elementua, kontsultatu erreferentzia iraunkor berri bat, gorde berriro protokoloa, eta gero konektatu aplikazioa itxita daemon-ak oraindik ebatzi dezakeela frogatzeko. Eduki erabiltzailearen pasahitza eta partekatutako sekretua elementu bereizietan, bakoitza bere egutegiaren arabera bira dadin, eta ez logan ez kontsultaren hiztegia ez erreferentzia bera. Heldulua ez da sekretu bat, baina hara doan mapa bat da.