તમે પ્રોફાઇલ ઇન્સ્ટોલ કરો છો, ટનલ ઉપર આવે છે અને બધું પૂરું લાગે છે. પછી ફોન રીબૂટ થાય છે, on-demand ફોરગ્રાઉન્ડમાં કોઈ એપ વિના કનેક્શન જગાડે છે, અને ટનલ શરૂ થવાનો ઇનકાર કરે છે. પ્રોફાઇલ હજી ત્યાં છે અને પાસવર્ડ હજી સાચો છે, તેથી જ આ નિષ્ફળતા લોકોને ખોટી જગ્યાએ શોધવા મોકલે છે. Network Extension પ્રોફાઇલમાંથી તમારું રહસ્ય વાંચી શકતું નથી: તેને કીરિંગ સંદર્ભ જોઈએ છે જે તે પોતે ઉકેલી શકે.

નીચેનું વોકથ્રુ આ હસ્તાંતરણ દ્વારા એક કનેક્શન પ્રયાસને અનુસરે છે, સંદર્ભ બનાવતી ક્વેરીથી લઈને તેને ચકાસતા રીબૂટ સુધી.

પ્રોફાઇલ હેન્ડલ સાચવે છે, રહસ્ય નહીં

NEVPNProtocol કોઈ કારણસર passwordReference અને sharedSecretReference ખુલ્લા રાખે છે. જ્યારે ડેમન ટનલ શરૂ કરે છે ત્યારે તે તમારી પ્રક્રિયાની અંદર ન પણ ચાલતું હોય, તેથી તે તમારો કોડ બોલાવીને પાસવર્ડ માગી શકતું નથી. તે કાયમી કીરિંગ સંદર્ભ વાંચે છે, તેને પોતાના સંદર્ભમાં ઉકેલે છે અને આઇટમ જાતે લાવે છે.

તમે તે સંદર્ભ કીરિંગને પૂછીને બનાવો છો, જે ડેટા માગવાથી અલગ વિનંતી છે:

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
]

પરત મળેલી ઑબ્જેક્ટ પ્રોટોકોલને આપો, આઇટમનો ડેટા નહીં. વ્યવહારમાં પ્રોફાઇલ નોંધે છે કે રહસ્ય ક્યાં રહે છે, તેથી જ કન્ફિગરેશનનું બેકઅપ પાસવર્ડને ચૂપચાપ plistમાં નકલ કરતું નથી.

API કેમ -50 જવાબ આપે છે

errSecParamનો અર્થ છે કે વિનંતી કે મૂલ્ય તે કામગીરી માટે ખોટા રચાયેલા હતા, અને સંદર્ભ તથા ડેટાની વિનંતીઓ મળી જાય ત્યારે આ ભૂલ સૌથી વધુ દેખાય છે. જ્યારે સ્વીકારતો કોડ સંદર્ભની રાહ જુએ ત્યારે ડેટા માગવો, passwordReferenceમાં કાચા બાઇટ્સ મૂકવા, અથવા એપ વાપરી ન શકે એવા એક્સેસ ગ્રુપ સાથે ક્વેરી કરવી, આ બધું તેને ઉત્પન્ન કરે છે.

રેપર લાઇબ્રેરીઓ આમાં આમંત્રણ આપે છે. બાઇટ્સ પરત આપતો હેલ્પર સંદર્ભ પરત આપતા હેલ્પર સાથે બદલી શકાતો નથી, તેથી સુધારો સામાન્ય રીતે બીજો પાસવર્ડ નહીં, બીજી ક્વેરી હોય છે.

એ જ અસંગતિ એવી પ્રોફાઇલ સમજાવે છે જે ફરિયાદ વિના સચવાય છે અને પછી કનેક્ટ થઈ શકતી નથી: સચવાયું છે તે બ્લોબ છે, હેન્ડલ નહીં, અને ડેમન પાસે ઉકેલવા જેવું કંઈ નથી.

સારી રીતે સચવાય, કનેક્શન વખતે નિષ્ફળ

સાચવવું તમારી એપનું સંદર્ભ વાપરે છે. કનેક્ટ થવું ડેમનનું વાપરે છે, અને બંનેની પહોંચ એક નથી. તેથી પ્રોફાઇલ સિમ્યુલેટરમાં તમે કરેલા દરેક પરીક્ષણમાં પાસ થઈને પ્રથમ on-demand શરૂઆતમાં નિષ્ફળ થઈ શકે છે.

રીબૂટના લક્ષણનો આકાર પણ એ જ છે: એપ ખુલ્લી હોય ત્યાં સુધી કામ કરે છે અને સિસ્ટમ પોતે ટનલ શરૂ કરે ત્યારે મરી જાય છે.

શિપિંગ પહેલાં બેકગ્રાઉન્ડ માર્ગ જાણી જોઈને ચકાસો. એપ બંધ હોય એમ on-demand કનેક્શન ઉત્પન્ન કરો, પછી એપનો લોગ નહીં પરંતુ ડિવાઇસ કન્સોલ વાંચો, કારણ કે નિષ્ફળતા તે પ્રક્રિયા નોંધે છે જેણે સંદર્ભ ઉકેલવાનો પ્રયાસ કર્યો. જો કન્સોલ દર્શાવે કે ડેમન આઇટમ નકારી રહ્યું છે, તો સંદર્ભ ઠીક છે અને સમસ્યા આઇટમની ઍક્સેસિબિલિટી છે.

રીબૂટ કામ કરશે કે નહીં તે ઍક્સેસિબિલિટી નક્કી કરે છે

ટનલ શરૂ કરતી કોઈપણ સિસ્ટમ પ્રક્રિયા માટે આઇટમ વાંચી શકાય તેવી હોવી જોઈએ, અને એપ ફોરગ્રાઉન્ડમાં હોય ત્યારે જે પ્રેક્ષકો હોય તેના કરતાં આ વિશાળ છે. તે મર્યાદા તમારા માટે ઍક્સેસિબિલિટી ગુણધર્મ પસંદ કરે છે. પ્રથમ અનલોક સુધી સુરક્ષિત આઇટમ ઉપકરણ એક વાર અનલોક થયા પછી બેકગ્રાઉન્ડ શરૂઆત માટે ઉપલબ્ધ છે; જે આઇટમ માગે છે કે ઉપકરણ અત્યારે અનલોક હોય તે ઉપલબ્ધ નથી.

વધુ કડક વર્ગ પસંદ કરવો લલચાવે છે અને તે જ લૉક થયેલા ફોન પર on-demand પ્રોફાઇલ તોડે છે.

વર્ગ બદલ્યા પછી હાલની આઇટમના ગુણધર્મો સંપાદિત કરવાને બદલે આઇટમ ફરી બનાવો, પછી નવા સંદર્ભ સાથે પ્રોટોકોલ ફરી સાચવો. હાલની આઇટમ પર ગુણધર્મ ફેરફારો હંમેશા દસ્તાવેજ જે વર્તન સૂચવે છે તે ઉત્પન્ન કરતા નથી, અને ફરી બનેલી આઇટમ શંકા દૂર કરે છે.

રોટેશન એ જ જગ્યા છે જ્યાં સાચવેલી પ્રોફાઇલો સડે છે

કીરિંગમાં પાસવર્ડ બદલવાથી સાચવેલી પ્રોફાઇલ કઈ વસ્તુ તરફ ઇશારો કરે છે તે આપોઆપ બદલાતું નથી. આઇટમ કાઢી નાખવી વધુ ખરાબ છે: પ્રોફાઇલ એવી વસ્તુનો સંદર્ભ રાખે છે જે હવે નથી, અને નિષ્ફળતા પ્રમાણીકરણના નકાર જેવી લાગે છે.

એક જ ક્રમમાં રોટેટ કરો. આઇટમ અપડેટ કરો, નવો કાયમી સંદર્ભ ક્વેરી કરો, પ્રોટોકોલ ફરી સાચવો, પછી એપ બંધ રાખીને કનેક્ટ થાઓ જેથી સાબિત થાય કે ડેમન હજી તેને ઉકેલી શકે છે. વપરાશકર્તાનો પાસવર્ડ અને શેર્ડ સિક્રેટ અલગ આઇટમમાં રાખો જેથી દરેક પોતાના સમયપત્રક પ્રમાણે ફરે, અને ક્વેરી ડિક્શનરી કે સંદર્ભ પોતે ક્યારેય લોગ કરશો નહીં. હેન્ડલ રહસ્ય નથી, પણ તે તરફનો નકશો છે.

સંબંધિત લેખો