🥇 हामीले ZeroTech मा कसरी Apple Safari र क्लाइन्ट सर्टिफिकेटहरू वेबसकेटहरूसँग जोड्यौं। प्रोहोस्टर

Статья будет полезна тем, кто:

क्लाइन्ट प्रमाणपत्र के हो थाहा छ र यसलाई मोबाइल सफारीमा किन वेबसकेटहरू चाहिन्छ भनेर बुझ्दछ;
म वेब सेवाहरू सीमित व्यक्तिहरूको सर्कलमा वा मेरो लागि मात्र प्रकाशित गर्न चाहन्छु;
सोच्दछ कि सबै कुरा पहिले नै कसैले गरिसकेको छ, र संसारलाई अलि बढी सुविधाजनक र सुरक्षित बनाउन चाहन्छ।

वेबसकेटको इतिहास लगभग 8 वर्ष पहिले सुरु भयो। पहिले, विधिहरू लामो http अनुरोधहरू (वास्तवमा प्रतिक्रियाहरू) को रूपमा प्रयोग गरिन्थ्यो: प्रयोगकर्ताको ब्राउजरले सर्भरमा अनुरोध पठायो र केहि जवाफ दिनको लागि प्रतिक्षा गर्‍यो, प्रतिक्रिया पछि यो फेरि जडान भयो र पर्खियो। तर त्यसपछि वेबसकेटहरू देखा पर्यो।

केहि वर्ष पहिले, हामीले शुद्ध PHP मा हाम्रो आफ्नै कार्यान्वयन विकास गर्यौं, जसले https अनुरोधहरू प्रयोग गर्न सक्दैन, किनकि यो लिङ्क तह हो। धेरै समय अघि, लगभग सबै वेब सर्भरहरूले प्रोक्सी अनुरोधहरू https र समर्थन जडान: अपग्रेड गर्न सिकेका थिए।

जब यो भयो, वेबसकेटहरू SPA अनुप्रयोगहरूको लागि लगभग पूर्वनिर्धारित सेवा भयो, किनभने सर्भरको पहलमा प्रयोगकर्तालाई सामग्री उपलब्ध गराउन कत्तिको सुविधाजनक छ (अर्को प्रयोगकर्ताबाट सन्देश पठाउनुहोस् वा छवि, कागजात, प्रस्तुतीकरणको नयाँ संस्करण डाउनलोड गर्नुहोस्। कि अरू कसैले हाल सम्पादन गरिरहेको छ)।

यद्यपि क्लाइन्ट सर्टिफिकेट धेरै समयको लागि वरिपरि रहेको छ, यो अझै पनि कमजोर रूपमा समर्थित छ, किनकि यसलाई बाइपास गर्ने प्रयास गर्दा यसले धेरै समस्याहरू सिर्जना गर्दछ। र (सम्भवतः :slightly_smiling_face: ) त्यसैले IOS ब्राउजरहरू (सफारी बाहेक सबै) यसलाई प्रयोग गर्न र स्थानीय प्रमाणपत्र भण्डारबाट अनुरोध गर्न चाहँदैनन्। लगइन/पास वा ssh कुञ्जीहरू वा फायरवाल मार्फत आवश्यक पोर्टहरू बन्द गर्ने तुलनामा प्रमाणपत्रहरूसँग धेरै फाइदाहरू छन्। तर यो के बारे मा छैन।

आईओएसमा, प्रमाणपत्र स्थापना गर्ने प्रक्रिया एकदम सरल छ (विशिष्ट बिना होइन), तर सामान्यतया यो निर्देशन अनुसार गरिन्छ, जसमध्ये इन्टरनेटमा धेरै छन् र सफारी ब्राउजरको लागि मात्र उपलब्ध छन्। दुर्भाग्यवश, सफारीलाई वेब सकेटहरूको लागि क्लाइन्ट सर्ट कसरी प्रयोग गर्ने भनेर थाहा छैन, तर इन्टरनेटमा यस्तो प्रमाणपत्र कसरी सिर्जना गर्ने भन्ने बारे धेरै निर्देशनहरू छन्, तर व्यवहारमा यो अप्राप्य छ।

वेबसकेटहरू बुझ्न, हामीले निम्न योजना प्रयोग गर्यौं: समस्या/परिकल्पना/समाधान।

समस्या: IOS र अन्य अनुप्रयोगहरूको लागि सफारी मोबाइल ब्राउजरमा क्लाइन्ट सर्टिफिकेटद्वारा सुरक्षित गरिएका स्रोतहरूमा प्रोक्सी अनुरोध गर्दा वेब सकेटहरूको लागि कुनै समर्थन छैन।

परिकल्पनाहरू:

यस्तो अपवाद कन्फिगर गर्न सम्भव छ सर्टिफिकेटहरू प्रयोग गर्नको लागि (त्यहाँ कुनै पनि हुने छैन भनेर थाहा छ) आन्तरिक/बाह्य प्रोक्सी स्रोतहरूको वेबसकेटहरूमा।
वेबसकेटहरूको लागि, तपाइँ अस्थायी सत्रहरू प्रयोग गरेर एक अद्वितीय, सुरक्षित र सुरक्षित जडान बनाउन सक्नुहुन्छ जुन सामान्य (गैर-वेबसकेट) ब्राउजर अनुरोधको समयमा उत्पन्न हुन्छ।
अस्थायी सत्रहरू एक प्रोक्सी वेब सर्भर प्रयोग गरेर लागू गर्न सकिन्छ (निर्मित मोड्युल र प्रकार्यहरू मात्र)।
अस्थायी सत्र टोकनहरू पहिले नै तयार-निर्मित Apache मोड्युलहरूको रूपमा लागू गरिएको छ।
तार्किक रूपमा अन्तरक्रिया संरचना डिजाइन गरेर अस्थायी सत्र टोकनहरू लागू गर्न सकिन्छ।

कार्यान्वयन पछि देखिने अवस्था।

कार्यको लक्ष्य: सेवाहरू र पूर्वाधारहरूको व्यवस्थापन अतिरिक्त कार्यक्रमहरू (जस्तै VPN) बिना IOS मा मोबाइल फोनबाट पहुँचयोग्य हुनुपर्छ, एकीकृत र सुरक्षित।

अतिरिक्त लक्ष्य: समय र स्रोतहरू/फोन ट्राफिक बचत गर्दै (वेब सकेट बिना केही सेवाहरूले अनावश्यक अनुरोधहरू उत्पन्न गर्दछ) मोबाइल इन्टरनेटमा सामग्रीको छिटो डेलिभरीको साथ।

कसरी जाँच गर्ने हो?

1. Открытие страниц:

— например, 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. वा विकासकर्ता कन्सोलमा:

परिकल्पना परीक्षण:

1. आन्तरिक/बाह्य प्रोक्सी स्रोतहरूको वेब सकेटहरूमा प्रमाणपत्रहरू प्रयोग गर्न (त्यहाँ कुनै पनि हुने छैन भनेर थाहा पाएर) यस्तो अपवाद कन्फिगर गर्न सम्भव छ।

2 समाधान यहाँ फेला पर्यो:

क) स्तरमा

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

पहुँच स्तर परिवर्तन गर्नुहोस्।

यो विधि निम्न nuances छ:

प्रमाणपत्र प्रमाणिकरण प्रोक्सी गरिएको स्रोतमा अनुरोध पछि हुन्छ, त्यो हो, पोस्ट अनुरोध ह्यान्डशेक। यसको मतलब प्रोक्सी पहिले लोड हुनेछ र त्यसपछि सुरक्षित सेवामा अनुरोध काटिनेछ। यो खराब छ, तर आलोचनात्मक छैन;
В протоколе http2. Он ещё находится в draft-е, и производители браузеров не знают, как его реализовать #info about tls1.3 http2 post handshake (not working now) RFC 8740 "HTTP/1.3 सँग TLS 2 प्रयोग गर्दै" लागू गर्नुहोस्;
यो प्रशोधन कसरी एकीकरण गर्ने स्पष्ट छैन।

ख) आधारभूत स्तरमा, प्रमाणपत्र बिना ssl लाई अनुमति दिनुहोस्।

SSLVerifyClient आवश्यक => SSLVerifyClient ऐच्छिक, तर यसले प्रोक्सी सर्भरको सुरक्षा स्तर घटाउँछ, किनकि यस्तो जडान प्रमाणपत्र बिना प्रक्रिया गरिनेछ। यद्यपि, तपाइँ निम्न निर्देशनको साथ प्रोक्सी सेवाहरूमा पहुँचलाई अस्वीकार गर्न सक्नुहुन्छ:

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"

थप विस्तृत जानकारी ssl को बारे मा लेख मा पाउन सकिन्छ: Apache सर्भर क्लाइन्ट प्रमाणपत्र प्रमाणीकरण

दुबै विकल्पहरू परीक्षण गरिएका थिए, विकल्प "b" यसको बहुमुखी प्रतिभा र http2 प्रोटोकलसँग अनुकूलताको लागि छनोट गरिएको थियो।

यस परिकल्पनाको प्रमाणीकरण पूरा गर्न, यसले कन्फिगरेसनको साथ धेरै प्रयोगहरू लियो; निम्न डिजाइनहरू परीक्षण गरियो:

यदि = आवश्यक = पुन: लेख्नुहोस्

परिणाम निम्न आधारभूत डिजाइन हो:

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>

प्रमाणपत्र मालिक द्वारा अवस्थित प्रमाणीकरणलाई ध्यानमा राख्दै, तर हराइरहेको प्रमाणपत्रको साथ, मैले उपलब्ध भ्यारीएबल SSl_PROTOCOL (SSL_CLIENT_S_DN_CN को सट्टा) को रूपमा एक गैर-अस्तित्व प्रमाणपत्र मालिक थप्नुपर्‍यो, कागजातमा थप विवरणहरू:

Apache Module mod_ssl

2. वेबसकेटहरूको लागि, तपाइँ अस्थायी सत्रहरू प्रयोग गरेर एक अद्वितीय, सुरक्षित र सुरक्षित जडान बनाउन सक्नुहुन्छ जुन सामान्य (गैर-वेबसकेट) ब्राउजर अनुरोधको समयमा उत्पन्न हुन्छ।

अघिल्लो अनुभवको आधारमा, तपाइँले नियमित (गैर-वेब सकेट) अनुरोधको समयमा वेब सकेट जडानहरूको लागि अस्थायी टोकनहरू तयार गर्न कन्फिगरेसनमा थप खण्ड थप्न आवश्यक छ।

#подготовка передача себе С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>

परीक्षणले काम गर्छ भन्ने देखाएको छ। प्रयोगकर्ताको ब्राउजर मार्फत कुकीहरू आफैंमा स्थानान्तरण गर्न सम्भव छ।

3. अस्थायी सत्रहरू एक प्रोक्सी वेब सर्भर (केवल निर्मित मोड्युल र प्रकार्यहरू) प्रयोग गरेर लागू गर्न सकिन्छ।

जसरी हामीले पहिले नै पत्ता लगायौं, Apache सँग धेरै कोर कार्यक्षमता छ जसले तपाईंलाई सशर्त निर्माणहरू सिर्जना गर्न अनुमति दिन्छ। यद्यपि, हामीलाई प्रयोगकर्ताको ब्राउजरमा हुँदा हाम्रो जानकारीलाई सुरक्षित गर्न साधन चाहिन्छ, त्यसैले हामीले के भण्डार गर्ने र किन, र कुन अन्तर्निहित प्रकार्यहरू प्रयोग गर्नेछौं भनेर स्थापना गर्छौं:

हामीलाई एउटा टोकन चाहिन्छ जुन सजिलै डिकोड गर्न सकिँदैन।
हामीलाई एउटा टोकन चाहिन्छ जुन यसमा निर्मित अप्रचलित छ र सर्भरमा अप्रचलितता जाँच गर्ने क्षमता छ।
हामीलाई एउटा टोकन चाहिन्छ जुन प्रमाणपत्रको मालिकसँग सम्बन्धित हुनेछ।

यसका लागि ह्यासिङ प्रकार्य, नुन, र टोकनको उमेरमा मिति चाहिन्छ। कागजातको आधारमा Apache HTTP सर्भरमा अभिव्यक्तिहरू हामीसँग यो सबै बाकस sha1 र %{TIME} बाहिर छ।

परिणाम यो डिजाइन थियो:

#нет сертификата, и обращение к 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>

लक्ष्य हासिल भएको छ, तर त्यहाँ सर्भर अप्रचलित हुने समस्याहरू छन् (तपाईले एक वर्ष पुरानो कुकी प्रयोग गर्न सक्नुहुन्छ), जसको मतलब टोकनहरू, आन्तरिक प्रयोगको लागि सुरक्षित भए पनि, औद्योगिक (बृहत्) प्रयोगको लागि असुरक्षित छन्।

4. अस्थायी सत्र टोकनहरू पहिले नै तयार-निर्मित Apache मोड्युलहरूको रूपमा लागू गरिएको छ।

एउटा महत्त्वपूर्ण समस्या अघिल्लो पुनरावृत्तिबाट रह्यो - टोकन बुढ्यौली नियन्त्रण गर्न असक्षमता।

हामी एक तयार मोड्युल खोज्दैछौं जसले यो गर्छ, शब्दहरू अनुसार: apache token json two factor auth

हो, त्यहाँ तयार मोड्युलहरू छन्, तर ती सबै विशिष्ट कार्यहरूमा बाँधिएका छन् र सत्र र अतिरिक्त कुकीहरू सुरु गर्ने रूपमा कलाकृतिहरू छन्। अर्थात् केही समयको लागि होइन ।
हामीलाई खोज्न पाँच घण्टा लाग्यो, जसले ठोस परिणाम दिन सकेन।

5. तार्किक रूपमा अन्तरक्रियाको संरचना डिजाइन गरेर अस्थायी सत्र टोकनहरू लागू गर्न सकिन्छ।

रेडिमेड मोड्युलहरू धेरै जटिल छन्, किनभने हामीलाई केवल केही कार्यहरू चाहिन्छ।

यसो भनिएको छ, मितिको साथ समस्या यो हो कि Apache को निर्मित प्रकार्यहरूले भविष्यबाट मिति उत्पन्न गर्न अनुमति दिँदैन, र अप्रचलितता जाँच गर्दा निर्मित प्रकार्यहरूमा कुनै गणितीय जोड/घटाउ हुँदैन।

त्यो हो, तपाईले लेख्न सक्नुहुन्न:

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

तपाईं केवल दुई संख्याहरू तुलना गर्न सक्नुहुन्छ।

При поиске обхода проблемы Safari нашлась интересная статья: क्लाइन्ट सर्टिफिकेटको साथ गृह सहायक सुरक्षित गर्दै (Safari/iOS सँग काम गर्दछ)
यसले Nginx को लागी Lua मा कोड को एक उदाहरण को वर्णन गर्दछ, र जुन, यो बाहिर निस्कियो, धेरै धेरै कन्फिगरेसन को त्यो भाग को तर्क दोहोर्याउँछ जुन हामीले पहिले नै लागू गरिसकेका छौं, ह्यासिंग को लागी hmac साल्टिङ विधि को प्रयोग को अपवाद को साथ (। यो Apache मा फेला परेन)।

यो स्पष्ट भयो कि लुआ स्पष्ट तर्क संग एक भाषा हो, र यो Apache को लागी केहि सरल गर्न सम्भव छ:

Nginx र Apache को साथ भिन्नता अध्ययन गर्दै:

र लुआ भाषा निर्माताबाट उपलब्ध कार्यहरू:
22.1 - मिति र समय

हामीले एउटा सानो लुआ फाइलमा env चरहरू सेट गर्ने तरिका फेला पार्‍यौं ताकि वर्तमानसँग तुलना गर्न भविष्यको मिति सेट गर्नुहोस्।

यो एक साधारण लुआ लिपि जस्तो देखिन्छ:

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

र पुरानो कुकी (टोकन) को म्याद सकिनु अघि आधा समय आउँदा कुकीहरूको संख्या अप्टिमाइजेसन र टोकनको प्रतिस्थापनको साथ यो सबै कुलमा कसरी काम गर्दछ:

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 बाट यस जानकारीको आधारमा पहुँच जाँचहरू पछि मात्र सक्रिय हुनेछ।

स्रोतको लिङ्क छविहरू.

अर्को कुरा।

सामान्यतया, यसले फरक पर्दैन कि निर्देशनहरू Apache (सायद Nginx पनि) कन्फिगरेसनमा कुन क्रममा लेखिएको छ, किनकि अन्तमा सबै कुरा प्रयोगकर्ताको अनुरोधको क्रममा क्रमबद्ध हुनेछ, जुन प्रक्रियाको लागि योजनासँग मेल खान्छ। लुआ लिपिहरू।

समापन:

कार्यान्वयन पछि देखिने अवस्था (लक्ष्य):
सेवाहरू र पूर्वाधारहरूको व्यवस्थापन मोबाइल फोनबाट आईओएसमा अतिरिक्त कार्यक्रमहरू (VPN) बिना उपलब्ध छ, एकीकृत र सुरक्षित।

लक्ष्य हासिल भएको छ, वेब सकेट काम गर्दछ र सुरक्षा को स्तर एक प्रमाणपत्र भन्दा कम छैन।

स्रोत: www.habr.com

हामीले ZeroTech मा कसरी Apple Safari र क्लाइन्ट सर्टिफिकेटहरू वेबसकेटहरूसँग जडान गर्यौं

एक टिप्पणी थप्न Отменить ответ