Profili VPN në iOS: passwordReference, jo fjalëkalimi

Instaloni një profil, tuneli ngrihet dhe gjithçka duket e përfunduar. Pastaj telefoni riniset, on-demand zgjon lidhjen pa asnjë aplikacion në plan të parë, dhe tuneli refuzon të nisë. Profili është ende aty dhe fjalëkalimi është ende i saktë, prandaj ky dështim i dërgon njerëzit të kërkojnë në vendin e gabuar. Një Network Extension nuk mund ta lexojë sekretin tuaj nga profili: i duhet një referencë e vargut të çelësave që mund ta zgjidhë vetë.

Ecja më poshtë ndjek një tentativë të vetme lidhjeje përmes asaj dorëzimi, nga pyetja që ndërton referencën deri te rinisja që e provon atë.

Profili ruan një dorezë, jo sekretin

NEVPNProtocol ekspozon passwordReference dhe sharedSecretReference për një arsye. Kur daemoni nis një tunel, ai mund të mos ekzekutohet brenda procesit tuaj, kështu që nuk mund të thërrasë kodin tuaj dhe të kërkojë fjalëkalim. Ai lexon një referencë të përhershme të vargut të çelësave, e zgjidh në kontekstin e vet dhe e merr artikullin vetë.

Ju e ndërtoni atë referencë duke e kërkuar nga vargu i çelësave, që është një kërkesë e ndryshme nga kërkesa për të dhënat:

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
]

Dorëzojini protokollit objektin e kthyer, jo të dhënat e artikullit. Në praktikë profili regjistron ku jeton sekreti, prandaj një kopje rezervë e konfigurimit nuk e dublon fjalëkalimin në heshtje në një plist.

Pse API përgjigjet -50

errSecParam do të thotë që kërkesa ose vlera ishte e keqformuar për operacionin, dhe është gabimi që shihet më shpesh kur kërkesat për referencë dhe për të dhëna përzihen. Kërkimi i të dhënave ndërsa kodi pritës pret një referencë, caktimi i bajteve të papërpunuara te passwordReference ose pyetja me një grup aksesi që aplikacioni nuk mund ta përdorë, të gjitha e prodhojnë atë.

Bibliotekat e mbështjelljes ftojnë për këtë. Një ndihmës që kthen bajte nuk është i këmbyeshëm me një që kthen një referencë, prandaj rregullimi është zakonisht një pyetje tjetër dhe jo një fjalëkalim tjetër.

I njëjti mospërputhje shpjegon një profil që ruhet pa ankesë dhe pastaj nuk lidhet: ajo që u ruajt është një blob, jo një dorezë, dhe daemoni nuk ka çfarë të zgjidhë.

Ruhet mirë, dështon në lidhje

Ruajtja ushtron kontekstin e aplikacionit tuaj. Lidhja ushtron atë të daemonit, dhe të dy nuk kanë të njëjtin akses. Prandaj një profil mund t'i kalojë të gjitha testet në simulator dhe të dështojë në nisjen e parë on-demand.

E njëjta formë është edhe simptoma e rinisjes: funksionon sa kohë aplikacioni është i hapur dhe vdes kur sistemi e nis vetë tunelin.

Testojeni me qëllim rrugën e sfondit përpara publikimit. Nxitni një lidhje on-demand me aplikacionin të mbyllur, pastaj lexoni konsolën e pajisjes dhe jo regjistrin e aplikacionit, sepse dështimin e regjistron procesi që u përpoq të zgjidhë referencën. Nëse konsola tregon se daemoni e refuzon artikullin, referenca është në rregull dhe problemi është aksesueshmëria e artikullit.

Aksesueshmëria vendos nëse një rinisje funksionon

Artikulli duhet të jetë i lexueshëm nga çdo proces sistemi që nis tunelin, dhe ky është një publik më i gjerë se aplikacioni juaj në plan të parë. Ai kufizim e zgjedh atributin e aksesueshmërisë për ju. Një artikull i mbrojtur deri në zhbllokimin e parë është i disponueshëm për një nisje në sfond pasi pajisja të jetë zhbllokuar një herë; një artikull që kërkon që pajisja të jetë e zhbllokuar tani nuk është.

Zgjedhja e klasës më të rreptë është joshëse dhe pikërisht ajo prish një profil on-demand në një telefon të kyçur.

Pasi të ndryshoni klasën, rikrijoni artikullin në vend që të modifikoni atribute te ai ekzistues, pastaj ruani përsëri protokollin me një referencë të freskët. Ndryshimet e atributeve te një artikull ekzistues nuk prodhojnë gjithmonë sjelljen që nënkupton dokumentacioni, dhe një artikull i rindërtuar e heq dyshimin.

Rrotullimi është vendi ku kalben profilet e ruajtura

Ndryshimi i fjalëkalimit në vargun e çelësave nuk ndryshon automatikisht atë ku tregon profili i ruajtur. Fshirja e artikullit është më keq: profili mban një referencë për diçka që nuk ekziston më, dhe dështimi duket si refuzim autentikimi.

Rrotullojeni në një rend. Përditësoni artikullin, kërkoni një referencë të re të përhershme, ruani përsëri protokollin, pastaj lidhuni me aplikacionin të mbyllur për të provuar se daemoni ende mund ta zgjidhë. Mbani fjalëkalimin e përdoruesit dhe sekretin e përbashkët në artikuj të veçantë, që secili të rrotullohet sipas kalendarit të vet, dhe asnjëherë mos regjistroni fjalorin e pyetjes ose vetë referencën. Doreza nuk është sekret, por është një hartë drejt tij.