ProHoster > Blog > Administrazioa > ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

Artikulua erabilgarria izango da:

  • badaki zer den Client Cert eta ulertzen du zergatik behar dituen websocket-ak Safari mugikorrean;
  • Web zerbitzuak argitaratu nahiko nituzke jende zirkulu mugatu bati edo nire buruari bakarrik;
  • uste du dagoeneko dena norbaitek egin duela, eta mundua apur bat erosoago eta seguruago egin nahiko luke.

Websocketen historia duela 8 urte inguru hasi zen. Aurretik, http eskaera luzeen (egia esan, erantzunak) moduan erabiltzen ziren metodoak: erabiltzailearen nabigatzaileak eskaera bat bidali zion zerbitzariari eta hark zerbait erantzuteko itxaron zuen, erantzunaren ondoren berriro konektatu eta itxaron zuen. Baina gero websocketak agertu ziren.

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

Duela urte batzuk, gure inplementazio propioa garatu genuen PHP hutsean, zeinak ezin ditu https eskaerak erabili, hau esteka geruza baita. Duela gutxi, ia web zerbitzari guztiek https-ren bidez proxy-eskaerak eta konexioa onartzen: berritzea ikasi zuten.

Hori gertatu zenean, websocket-ak SPA aplikazioetarako ia zerbitzu lehenetsia bihurtu ziren, zeren erosoa den erabiltzaileari zerbitzariaren ekimenez edukia eskaintzea (beste erabiltzaile baten mezu bat bidali edo irudi, dokumentu, aurkezpen baten bertsio berri bat deskargatu). beste norbait une honetan editatzen ari dela) .

Bezeroaren Ziurtagiria denbora dezente egon bada ere, oraindik gaizki onartzen da, arazo asko sortzen baititu saihesten saiatzean. Eta (baliteke :slightly_smiling_face: ) horregatik IOS arakatzaileek (Safari izan ezik) ez dute erabili nahi eta tokiko ziurtagiri dendatik eskatu. Ziurtagiriek abantaila asko dituzte login/pass edo ssh gakoekin edo beharrezko atakak suebaki baten bidez ixtearekin alderatuta. Baina hori ez da hori.

iOS-en, ziurtagiri bat instalatzeko prozedura nahiko sinplea da (ez dago zehaztasunik gabe), baina, oro har, argibideen arabera egiten da, Interneten asko daude eta Safari nabigatzailerako bakarrik daude eskuragarri. Zoritxarrez, Safari-k ez daki nola erabili Client Π‘ert web socketetarako, baina Interneten argibide asko daude ziurtagiri hori nola sortu jakiteko, baina praktikan hori ezinezkoa da.

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

Websocketak ulertzeko, plan hau erabili dugu: arazoa/hipotesia/konponbidea.

Arazoa: ez dago laguntzarik web socketetarako Safari mugikorreko IOSrako eta ziurtagirien euskarria gaitu duten beste aplikazioetarako bezero-ziurtagiri batek babestuta dauden baliabideetara eskaerak proxyz bidaltzean.

Hipotesiak:

  1. Posible da horrelako salbuespen bat konfiguratu ziurtagiriak erabiltzeko (jakinduta ez dela egongo) barne/kanpo proxy baliabideen websocketetan.
  2. Websocketetarako, konexio bakarra, segurua eta defendagarria egin dezakezu arakatzailearen eskaera arrunt batean (websocket ez dena) sortzen diren aldi baterako saioak erabiliz.
  3. Aldi baterako saioak proxy web zerbitzari bakarra erabiliz inplementa daitezke (modulu eta funtzio integratuak soilik).
  4. Aldi baterako saio-tokenak prest dauden Apache modulu gisa inplementatu dira.
  5. Aldi baterako saio-tokenak interakzio-egitura logikoki diseinatuz inplementa daitezke.

Ezarpenaren ondoren ikusgai dagoen egoera.

Lanaren helburua: zerbitzuen eta azpiegituren kudeaketa IOSeko telefono mugikor batetik eskuragarri egon behar da programa gehigarririk gabe (adibidez, VPN), bateratua eta segurua.

Helburu gehigarria: denbora eta baliabideak/telefono trafikoa aurreztea (web socket gabeko zerbitzu batzuek alferrikako eskaerak sortzen dituzte) Internet mugikorrean edukia azkarrago bidaltzearekin.

Nola egiaztatu?

1. Orriak irekitzea: 

β€” Π½Π°ΠΏΡ€ΠΈΠΌΠ΅Ρ€, https://teamcity.yourdomain.com Π² мобильном Π±Ρ€Π°ΡƒΠ·Π΅Ρ€Π΅ Safari (доступСн Ρ‚Π°ΠΊΠΆΠ΅ Π² дСсктопной вСрсии) β€” Π²Ρ‹Π·Ρ‹Π²Π°Π΅Ρ‚ ΡƒΡΠΏΠ΅ΡˆΠ½ΠΎΠ΅ ΠΏΠΎΠ΄ΠΊΠ»ΡŽΡ‡Π΅Π½ΠΈΠ΅ ΠΊ Π²Π΅Π±-сокСтам.
β€” Π½Π°ΠΏΡ€ΠΈΠΌΠ΅Ρ€, https://teamcity.yourdomain.com/admin/admin.html?item=diagnostics&tab=webS…— ΠΏΠΎΠΊΠ°Π·Ρ‹Π²Π°Π΅Ρ‚ ping/pong.
β€” Π½Π°ΠΏΡ€ΠΈΠΌΠ΅Ρ€, https://rancher.yourdomain.com/p/c-84bnv:p-vkszd/workload/deployment:danidb:ph…-> viewlogs β€” ΠΏΠΎΠΊΠ°Π·Ρ‹Π²Π°Π΅Ρ‚ Π»ΠΎΠ³ΠΈ ΠΊΠΎΠ½Ρ‚Π΅ΠΉΠ½Π΅Ρ€Π°.

2. Edo garatzaileen kontsolan:

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

Hipotesiaren azterketa:

1. Posible da halako salbuespen bat konfiguratu ziurtagiriak erabiltzeko (jakinduta ez dela egongo) proxy-baliabideen barne/kanpoko web socketetan.

2 irtenbide aurkitu dira hemen:

a) Mailan 

<Location sock*> SSLVerifyClient optional </Location>
<Location /> SSLVerifyClient require </Location>

sarbide-maila aldatzea.

Metodo honek Γ±abardura hauek ditu:

  • Ziurtagiriaren egiaztapena proxy baliabideari egindako eskaeraren ondoren gertatzen da, hau da, eskaeraren esku-ematearen ondoren. Horrek esan nahi du proxyak lehenik kargatuko duela eta ondoren babestutako zerbitzurako eskaera moztuko duela. Hau txarra da, baina ez da kritikoa;
  • http2 protokoloan. Zirriborroan dago oraindik, eta arakatzaileen fabrikatzaileek ez dakite nola inplementatu #info info tls1.3 http2 post handshake (orain ez da funtzionatzen) Inplementatu RFC 8740 "TLS 1.3 erabiltzea HTTP/2-rekin";
  • Ez dago argi prozesamendu hori nola bateratu.

b) Oinarrizko mailan, ssl baimendu ziurtagiririk gabe.

SSLVerifyClient require => SSLVerifyClient aukerakoa, baina honek proxy zerbitzariaren segurtasun maila murrizten du, konexio hori ziurtagiririk gabe prozesatuko baita. Hala ere, proxy zerbitzuetarako sarbidea uka dezakezu honako zuzentarau honekin:

RewriteEngine        on
RewriteCond     %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteRule     .? - [F]
ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

Informazio zehatzagoa ssl-i buruzko artikuluan aurki daiteke: Apache zerbitzariaren bezero-ziurtagiriaren autentifikazioa

Bi aukerak probatu ziren, β€œb” aukera aukeratu zen bere aldakortasunagatik eta http2 protokoloarekin bateragarriagatik.

Hipotesi honen egiaztapena osatzeko, esperimentu asko egin behar izan dira konfigurazioarekin; honako diseinu hauek probatu dira:

bada = eskatu = berridatzi

Emaitza oinarrizko diseinu hau da:

SSLVerifyClient optional
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule     .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

#websocket for safari without cert auth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
...
    #Π·Π°ΠΌΠ΅Ρ‰Π°Π΅ΠΌ Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π²Π»Π°Π΄Π΅Π»ΡŒΡ†Ρƒ сСртификата Π½Π° Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π½ΠΎΠΌΠ΅Ρ€Ρƒ ΠΏΡ€ΠΎΡ‚ΠΎΠΊΠΎΠ»Π°
    SSLUserName SSl_PROTOCOL
</If>
</If>

Ziurtagiriaren jabeak dagoen baimena kontuan hartuta, baina ziurtagiri bat falta zenez, existitzen ez den ziurtagiriaren jabea gehitu behar izan dut eskuragarri dauden aldagaietako SSl_PROTOCOL (SSL_CLIENT_S_DN_CNren ordez), xehetasun gehiago dokumentazioan:

Apache modulua mod_ssl

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

2. Websocketetarako, konexio bakarra, segurua eta babestua egin dezakezu arakatzaile-eskaera arrunt batean (ez-websocket) sortzen diren aldi baterako saioak erabiliz.

Aurreko esperientzian oinarrituta, atal gehigarri bat gehitu behar diozu konfigurazioari web socket konexioetarako aldi baterako tokenak prestatzeko ohiko eskaera batean (web ez den socket).

#ΠΏΠΎΠ΄Π³ΠΎΡ‚ΠΎΠ²ΠΊΠ° ΠΏΠ΅Ρ€Π΅Π΄Π°Ρ‡Π° сСбС Π‘ookie Ρ‡Π΅Ρ€Π΅Π· ΠΏΠΎΠ»ΡŒΠ·ΠΎΠ²Π°Ρ‚Π΅Π»ΡŒΡΠΊΠΈΠΉ Π±Ρ€Π°ΡƒΠ·Π΅Ρ€
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
Header set Set-Cookie "websocket-allowed=true; path=/; Max-Age=100"
</If>
</If>

#ΠΏΡ€ΠΎΠ²Π΅Ρ€ΠΊΠ° Cookie для установлСния Π²Π΅Π±-сокСт соСдинСния
<source lang="javascript">
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
#check for exists cookie

#get and check
SetEnvIf Cookie "websocket-allowed=(.*)" env-var-name=$1

#or rewrite rule
RewriteCond %{HTTP_COOKIE} !^.*mycookie.*$

#or if
<If "%{HTTP_COOKIE} =~ /(^|; )cookie-names*=s*some-val(;|$)/ >
</If

</If>
</If>

Probak frogatu du funtzionatzen duela. Posible da Cookieak transferitzea erabiltzailearen nabigatzailearen bidez.

3. Aldi baterako saioak proxy web zerbitzari bakarra erabiliz inplementa daitezke (modulu eta funtzio integratuak soilik).

Lehenago jakin genuenez, Apache-k baldintzazko eraikuntzak sortzeko aukera ematen duen oinarrizko funtzionalitate asko ditu. Hala ere, gure informazioa babesteko baliabideak behar ditugu erabiltzailearen nabigatzailean dagoen bitartean, beraz, zer eta zergatik gorde behar dugun eta zer funtzio integratuak erabiliko ditugun zehaztuko dugu:

  • Erraz deskodetu ezin den token bat behar dugu.
  • Zaharkitzea eta zerbitzarian zaharkitzea egiaztatzeko gaitasuna duen token bat behar dugu.
  • Ziurtagiriaren jabearekin elkartuko den token bat behar dugu.

Horretarako hashing funtzioa, gatza eta data behar dira tokena zahartzeko. Dokumentazioan oinarrituta Adierazpenak Apache HTTP zerbitzarian dena kaxatik kanpo daukagu ​​sha1 eta %{TIME}.

Emaitza diseinu hau izan zen:

#Π½Π΅Ρ‚ сСртификата, ΠΈ ΠΎΠ±Ρ€Π°Ρ‰Π΅Π½ΠΈΠ΅ ΠΊ websocket
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
    SetEnvIf Cookie "zt-cert-sha1=([^;]+)" zt-cert-sha1=$1
    SetEnvIf Cookie "zt-cert-uid=([^;]+)" zt-cert-uid=$1
    SetEnvIf Cookie "zt-cert-date=([^;]+)" zt-cert-date=$1

#Ρ‚ΠΎΠ»ΡŒΠΊΠΎ Ρ‚Π°ΠΊ ΠΌΠΎΠΆΠ½ΠΎ Ρ€Π°Π±ΠΎΡ‚Π°Ρ‚ΡŒ с ΠΏΠ΅Ρ€Π΅ΠΌΠ΅Π½Π½Ρ‹ΠΌΠΈ, ΠΏΠΎΠ»ΡƒΡ‡Π΅Π½Π½Ρ‹ΠΌΠΈ Π² env-Π°Ρ… Π² этот ΠΌΠΎΠΌΠ΅Π½Ρ‚ Π²Ρ€Π΅ΠΌΠ΅Π½ΠΈ, Π±ΠΎΠ»Π΅Π΅ ΠΎΠ½ΠΈ Π½ΠΈΠ³Π΄Π΅ Π½Π΅ доступны для Ρ„ΡƒΠ½ΠΊΡ†ΠΈΠΈ Ρ…Π΅ΡˆΠΈΡ€ΠΎΠ²Π°Π½ΠΈΡ (ΠΏΠΎ ΠΎΡ‚Π΄Π΅Π»ΡŒΠ½ΠΎΡΡ‚ΠΈ ΠΌΠΎΠΆΠ½ΠΎ, Π½ΠΎ Π½Π΅ вмСстС, Π΄Π° ΠΈ Π΅Ρ‰Ρ‘ с Ρ…Π΅ΡˆΠΈΡ€ΠΎΠ²Π°Π½ΠΈΠ΅ΠΌ)
    <RequireAll>
        Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
        Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
    </RequireAll>
</If>
</If>

#Π΅ΡΡ‚ΡŒ сСртификат, Π·Π°ΠΏΡ€Π°ΡˆΠΈΠ²Π°Π΅Ρ‚ΡΡ Π½Π΅ websocket
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
    SetEnvIf Cookie "zt-cert-sha1=([^;]+)" HAVE_zt-cert-sha1=$1

    SetEnv zt_cert "path=/; HttpOnly;Secure;SameSite=Strict"
#НовыС ΠΊΡƒΠΊΠΈ ставятся, Ссли старых Π½Π΅Ρ‚
    Header add Set-Cookie "expr=zt-cert-sha1=%{sha1:salt1%{TIME}salt3%{SSL_CLIENT_S_DN_CN}salt2};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
    Header add Set-Cookie "expr=zt-cert-uid=%{SSL_CLIENT_S_DN_CN};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
    Header add Set-Cookie "expr=zt-cert-date=%{TIME};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
</If>
</If>

Helburua lortu da, baina zerbitzariaren zaharkitzearekin arazoak daude (urte bateko Cookie bat erabil dezakezu), hau da, tokenak, barne erabilerarako seguruak izan arren, ez dira seguruak industriarako (masa) erabilerarako.

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

4. Aldi baterako saio-tokenak prest dauden Apache modulu gisa inplementatu dira.

Aurreko iteraziotik arazo esanguratsu bat geratu zen: tokenen zahartzea kontrolatzeko ezintasuna.

Hau egiten duen prest egindako modulu baten bila gabiltza, hitzen arabera: apache token json two factor auth

Bai, badaude prest egindako moduluak, baina denak ekintza zehatzei lotuta daude eta saio bat hasteko eta Cookie osagarriak dituzte. Hau da, ez denbora baterako.
Bost ordu behar izan ditugu bilaketak egiteko, eta horrek ez du emaitza zehatzik eman.

5. Aldi baterako saio-tokenak inplementa daitezke interakzioen egitura logikoki diseinatuz.

Prest egindako moduluak konplexuegiak dira, funtzio pare bat baino ez ditugulako behar.

Hori esanda, dataren arazoa da Apache-ren funtzio integratuek ez dutela etorkizuneko datarik sortzen uzten, eta ez dago batuketa/kenketa matematikorik integratutako funtzioetan zaharkituta dagoen egiaztatzean.

Hau da, ezin duzu idatzi:

(%{env:zt-cert-date} + 30) > %{DATE}

Bi zenbaki bakarrik konparatu ditzakezu.

Safari arazoari irtenbide bat bilatzen ari nintzela, artikulu interesgarri bat aurkitu dut: HomeAssistant bezeroaren ziurtagiriekin ziurtatzea (Safari/iOS-ekin funtzionatzen du)
Nginx-erako Lua-n kode-adibide bat deskribatzen du, eta, ondorioz, dagoeneko inplementatu dugun konfigurazioaren zati horren logika oso errepikatzen du, hasherako hmac salting metodoa erabiltzea izan ezik ( hau ez zen Apache-n aurkitu).

Argi geratu zen Lua logika argia duen hizkuntza bat dela, eta posible dela zerbait sinplea egitea Apacherentzat:

Nginx eta Apache-rekin ezberdintasuna aztertu ondoren:

Eta Lua hizkuntzaren fabrikatzailearen funtzio eskuragarriak:
22.1 – Data eta ordua

Lua fitxategi txiki batean env aldagaiak ezartzeko modu bat aurkitu dugu etorkizuneko data bat ezartzeko egungoarekin alderatzeko.

Hau da Lua script sinple baten itxura:

require 'apache2'

function handler(r)
    local fmt = '%Y%m%d%H%M%S'
    local timeout = 3600 -- 1 hour

    r.notes['zt-cert-timeout'] = timeout
    r.notes['zt-cert-date-next'] = os.date(fmt,os.time()+timeout)
    r.notes['zt-cert-date-halfnext'] = os.date(fmt,os.time()+ (timeout/2))
    r.notes['zt-cert-date-now'] = os.date(fmt,os.time())

    return apache2.OK
end

Eta horrela funtzionatzen du guztiak guztira, Cookie-kopurua optimizatuz eta tokena ordezkatuz Cookie zaharra (token) iraungi baino denboraren erdia igarotzen denean:

SSLVerifyClient optional

#LuaScope thread
#generate event variables zt-cert-date-next
LuaHookAccessChecker /usr/local/etc/apache24/sslincludes/websocket_token.lua handler early

#Π·Π°ΠΏΡ€Π΅Ρ‰Π°Π΅ΠΌ Π±Π΅Π· сСртификата Ρ‡Ρ‚ΠΎ-Ρ‚ΠΎ Π΅Ρ‰Ρ‘, ΠΊΡ€ΠΎΠΌΠ΅ webscoket
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule     .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"

#websocket for safari without certauth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
    SetEnvIf Cookie "zt-cert=([^,;]+),([^,;]+),[^,;]+,([^,;]+)" zt-cert-sha1=$1 zt-cert-date=$2 zt-cert-uid=$3

    <RequireAll>
        Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
        Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
        Require expr %{env:zt-cert-date} -ge %{env:zt-cert-date-now}
    </RequireAll>
   
    #Π·Π°ΠΌΠ΅Ρ‰Π°Π΅ΠΌ Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π²Π»Π°Π΄Π΅Π»ΡŒΡ†Ρƒ сСртификата Π½Π° Π°Π²Ρ‚ΠΎΡ€ΠΈΠ·Π°Ρ†ΠΈΡŽ ΠΏΠΎ Π½ΠΎΠΌΠ΅Ρ€Ρƒ ΠΏΡ€ΠΎΡ‚ΠΎΠΊΠΎΠ»Π°
    SSLUserName SSl_PROTOCOL
    SSLOptions -FakeBasicAuth
</If>
</If>

<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
    SetEnvIf Cookie "zt-cert=([^,;]+),[^,;]+,([^,;]+)" HAVE_zt-cert-sha1=$1 HAVE_zt-cert-date-halfnow=$2
    SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1

    Define zt-cert "path=/;Max-Age=%{env:zt-cert-timeout};HttpOnly;Secure;SameSite=Strict"
    Define dates_user "%{env:zt-cert-date-next},%{env:zt-cert-date-halfnext},%{SSL_CLIENT_S_DN_CN}"
    Header set Set-Cookie "expr=zt-cert=%{sha1:salt1%{env:zt-cert-date-next}sal3%{SSL_CLIENT_S_DN_CN}salt2},${dates_user};${zt-cert}" env=!HAVE_zt-cert-sha1-found
</If>
</If>

SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1
Ρ€Π°Π±ΠΎΡ‚Π°Π΅Ρ‚,

Π° Ρ‚Π°ΠΊ Ρ€Π°Π±ΠΎΡ‚Π°Ρ‚ΡŒ Π½Π΅ Π±ΡƒΠ΄Π΅Ρ‚
SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge  env('zt-cert-date-now') && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1

LuaHookAccessChecker Nginx-en informazio honetan oinarritutako sarbide-egiaztapenen ondoren bakarrik aktibatuko baita.

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

Esteka iturrira Irudia.

Beste puntu bat.

Oro har, ez du axola zuzentarauak Apache (ziurrenik Nginx) konfigurazioan idazten diren zer ordenatan idazten diren, azkenean dena erabiltzailearen eskaeraren ordenaren arabera ordenatuko baita, prozesatzeko eskemarekin bat datorrena. Lua gidoiak.

Osatzea:

Inplementatu ondoren ikusgai dagoen egoera (helburua):
zerbitzuen eta azpiegituren kudeaketa IOSeko telefono mugikor batetik eskuragarri dago programa gehigarririk (VPN), bateratua eta segurua.

Helburua lortu da, web socket-ek funtzionatzen dute eta segurtasun maila dute ziurtagiri bat baino gutxiago.

ZeroTech-en nola konektatu genuen Apple Safari eta bezeroen ziurtagiriak websocketekin

Iturria: www.habr.com

Gehitu iruzkin berria