🥇ZeroTech හි අපි Apple Safari සහ සේවාදායක සහතික වෙබ් සොකට් සමඟ සම්බන්ධ කළ ආකාරය

ලිපිය පහත සඳහන් අයට ප්‍රයෝජනවත් වනු ඇත:

Client Cert යනු කුමක්දැයි දන්නා අතර එයට ජංගම Safari හි websockets අවශ්‍ය වන්නේ මන්දැයි තේරුම් ගනී;
මම සීමිත පුද්ගලයන් පිරිසකට හෝ මට පමණක් වෙබ් සේවා පළ කිරීමට කැමතියි;
සෑම දෙයක්ම දැනටමත් යමෙකු විසින් කර ඇති බව සිතන අතර, ලෝකය ටිකක් පහසු සහ ආරක්ෂිත කිරීමට කැමතියි.

වෙබ්සොකට් වල ඉතිහාසය මීට වසර 8 කට පමණ පෙර ආරම්භ විය. මීට පෙර, දිගු http ඉල්ලීම් (සැබවින්ම ප්රතිචාර) ආකාරයෙන් ක්රම භාවිතා කරන ලදී: පරිශීලකයාගේ බ්රවුසරය සේවාදායකය වෙත ඉල්ලීමක් යවා යමක් පිළිතුරු දෙන තෙක් බලා සිටියේය, ප්රතිචාරයෙන් පසුව එය නැවත සම්බන්ධ වී බලා සිටියේය. නමුත් පසුව වෙබ්සොකට් දර්ශනය විය.

මීට වසර කිහිපයකට පෙර, අපි අපගේම ක්‍රියාත්මක කිරීමක් පිරිසිදු PHP තුළ සංවර්ධනය කළෙමු, එයට https ඉල්ලීම් භාවිතා කළ නොහැක, මෙය සබැඳි ස්තරය වන බැවිනි. බොහෝ කලකට පෙර, සියලුම වෙබ් සේවාදායකයන් පාහේ https හරහා ප්‍රොක්සි ඉල්ලීම් කිරීමට ඉගෙන ගත් අතර සම්බන්ධතාව: උත්ශ්‍රේණි කිරීමට සහය දක්වයි.

මෙය සිදු වූ විට, වෙබ්සොකට් SPA යෙදුම් සඳහා පෙරනිමි සේවාව බවට පත් විය, මන්ද සේවාදායකයේ මුලපිරීම මත පරිශීලකයාට අන්තර්ගතය සැපයීම කෙතරම් පහසුද (වෙනත් පරිශීලකයෙකුගෙන් පණිවිඩයක් සම්ප්‍රේෂණය කරන්න හෝ රූපයක, ලේඛනයේ, ඉදිරිපත් කිරීමේ නව අනුවාදයක් බාගන්න. වෙනත් කෙනෙකු දැනට සංස්කරණය කරමින් සිටින බව) .

සේවාලාභී සහතිකය සෑහෙන කාලයක් තිස්සේ පැවතුනද, එය මඟ හැරීමට උත්සාහ කිරීමේදී ගැටලු රාශියක් ඇති කරන බැවින්, එය තවමත් දුර්වල ලෙස සහාය දක්වයි. සහ (සමහර විට :slightly_smiling_face: ) ඒ නිසා IOS බ්‍රවුසර (සෆාරි හැර අනෙක් සියල්ල) එය භාවිතා කිරීමට සහ ප්‍රාදේශීය සහතික ගබඩාවෙන් ඉල්ලීමට අවශ්‍ය නොවේ. ලොගින්/පාස් හෝ ssh යතුරු හෝ ෆයර්වෝලයක් හරහා අවශ්‍ය වරායන් වැසීමට සාපේක්ෂව සහතික වලට බොහෝ වාසි ඇත. නමුත් මේ කියන්න යන්නේ ඒ ගැන නෙවෙයි.

IOS හි, සහතිකයක් ස්ථාපනය කිරීමේ ක්‍රියා පටිපාටිය තරමක් සරල ය (විශේෂිත කරුණු නොමැතිව නොවේ), නමුත් පොදුවේ එය උපදෙස් වලට අනුව සිදු කරනු ලැබේ, ඒවායින් අන්තර්ජාලයේ බොහෝ දේ ඇති අතර ඒවා සෆාරි බ්‍රව්සරයට පමණක් ලබා ගත හැකිය. අවාසනාවකට මෙන්, Safari වෙබ් සොකට් සඳහා Client Сert භාවිතා කරන්නේ කෙසේදැයි නොදනී, නමුත් එවැනි සහතිකයක් නිර්මාණය කරන්නේ කෙසේද යන්න පිළිබඳව අන්තර්ජාලයේ බොහෝ උපදෙස් ඇත, නමුත් ප්‍රායෝගිකව මෙය සාක්ෂාත් කරගත නොහැක.

වෙබ් සොකට් තේරුම් ගැනීමට, අපි පහත සැලැස්ම භාවිතා කළෙමු: ගැටලුව/උපකල්පනය/විසඳුම.

ගැටලුව: IOS සහ සහතික සහය සක්‍රීය කර ඇති අනෙකුත් යෙදුම් සඳහා Safari ජංගම බ්‍රවුසරයේ සේවාදායක සහතිකයක් මඟින් ආරක්‍ෂිත සම්පත් වෙත ඉල්ලීම් ප්‍රොක්සි කිරීමේදී වෙබ් සොකට් සඳහා සහායක් නොමැත.

උපකල්පන:

අභ්‍යන්තර/බාහිර ප්‍රොක්සිඩ් සම්පත් වල වෙබ් සොකට් වලට සහතික (කිසිවක් නොමැති බව දැනගෙන) භාවිතා කිරීමට එවැනි ව්‍යතිරේකයක් වින්‍යාසගත කළ හැක.
වෙබ් සොකට් සඳහා, ඔබට සාමාන්‍ය (වෙබ්සොකට් නොවන) බ්‍රවුසර ඉල්ලීමක් තුළ ජනනය කරන තාවකාලික සැසි භාවිතයෙන් අද්විතීය, ආරක්ෂිත සහ ආරක්‍ෂිත සම්බන්ධතාවයක් ඇති කර ගත හැකිය.
එක් ප්‍රොක්සි වෙබ් සේවාදායකයක් භාවිතයෙන් තාවකාලික සැසි ක්‍රියාත්මක කළ හැක (බිල්ට් මොඩියුල සහ කාර්යයන් පමණි).
තාවකාලික සැසි ටෝකන දැනටමත් සූදානම් 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 ක් මෙහි සොයා ගන්නා ලදී:

a) මට්ටමේ

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

ප්රවේශ මට්ටම වෙනස් කරන්න.

මෙම ක්‍රමයට පහත සූක්ෂ්මතා ඇත:

සහතික සත්‍යාපනය සිදු වන්නේ ප්‍රොක්සි කරන ලද සම්පත වෙත ඉල්ලීමකින් පසුවය, එනම්, පසු ඉල්ලීම් අතට අත දීම. මෙයින් අදහස් කරන්නේ ප්‍රොක්සිය පළමුව පූරණය වන අතර පසුව ආරක්ෂිත සේවාව වෙත ඉල්ලීම කපා හරින බවයි. මෙය නරකයි, නමුත් විවේචනාත්මක නොවේ;
http2 ප්‍රොටෝකෝලය තුළ. එය තවමත් කෙටුම්පතේ පවතින අතර බ්‍රවුසර නිෂ්පාදකයින් එය ක්‍රියාත්මක කරන්නේ කෙසේදැයි නොදනී #tls1.3 http2 post handshake (දැන් ක්‍රියා නොකරයි) 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 Server Client Certificate Authentication

විකල්ප දෙකම පරීක්‍ෂා කරන ලදී, එහි බහුකාර්යතාව සහ http2 ප්‍රොටෝකෝලය සමඟ ගැළපුම සඳහා “b” විකල්පය තෝරා ගන්නා ලදී.

මෙම කල්පිතයේ සත්‍යාපනය සම්පූර්ණ කිරීම සඳහා, එය වින්‍යාසය සමඟ බොහෝ අත්හදා බැලීම් සිදු කරන ලදී; පහත මෝස්තර පරීක්ෂා කරන ලදී:

if = අවශ්යයි = නැවත ලියන්න

එහි ප්‍රතිඵලය වන්නේ පහත මූලික සැලසුමයි.

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 සතුව බොහෝ මූලික ක්‍රියාකාරීත්වයක් ඇති අතර එමඟින් ඔබට කොන්දේසි සහිත ඉදිකිරීම් නිර්මාණය කිරීමට ඉඩ සලසයි. කෙසේ වෙතත්, අපගේ තොරතුරු පරිශීලකයාගේ බ්‍රවුසරයේ ඇති විට ඒවා ආරක්ෂා කිරීමට අපට ක්‍රම අවශ්‍ය වේ, එබැවින් අපි ගබඩා කළ යුත්තේ කුමක්ද සහ ඇයි, සහ අප භාවිතා කරන බිල්ට් ක්‍රියාකාරකම් මොනවාද යන්න තහවුරු කරමු:

අපිට ලේසියෙන් decode කරන්න බැරි ටෝකනයක් ඕන.
අපට අවශ්‍ය වන්නේ යල්පැන ඇති බව සහ සේවාදායකයේ යල්පැන ඇති බව පරීක්ෂා කිරීමේ හැකියාව ඇති ටෝකනයකි.
සහතිකයේ හිමිකරු සමඟ සම්බන්ධ වන ටෝකනයක් අපට අවශ්‍යයි.

මේ සඳහා හෂිං ශ්‍රිතයක්, ලුණු සහ ටෝකනය වයස්ගත වීමට දිනයක් අවශ්‍ය වේ. ලියකියවිලි මත පදනම්ව 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}

ඔබට සංසන්දනය කළ හැක්කේ අංක දෙකක් පමණි.

සෆාරි ගැටලුව සඳහා විසඳුමක් සොයමින් සිටියදී, මට රසවත් ලිපියක් හමු විය: සේවාලාභී සහතික සහිත HomeAssistant සුරක්ෂිත කිරීම (Safari/iOS සමඟ ක්‍රියා කරයි)
එය Nginx සඳහා Lua හි කේතයේ උදාහරණයක් විස්තර කරන අතර, එය හැෂිං සඳහා hmac ලුණු දැමීමේ ක්‍රමය භාවිතා කිරීම හැර, අප දැනටමත් ක්‍රියාත්මක කර ඇති වින්‍යාසයේ එම කොටසෙහි තර්කනය පුනරාවර්තනය කරයි ( මෙය Apache හි හමු නොවීය.

Lua යනු පැහැදිලි තර්කයක් සහිත භාෂාවක් බව පැහැදිලි වූ අතර Apache සඳහා සරල දෙයක් කළ හැකිය:

Nginx සහ Apache සමඟ වෙනස අධ්‍යයනය කිරීමෙන් පසු:

සහ Lua භාෂා නිෂ්පාදකයාගෙන් ලබාගත හැකි කාර්යයන්:
22.1 - දිනය සහ වේලාව

වර්තමාන එක සමඟ සංසන්දනය කිරීම සඳහා අනාගතයේ සිට දිනයක් නියම කිරීම සඳහා කුඩා Lua ගොනුවක env විචල්‍ය සැකසීමට ක්‍රමයක් අපි සොයා ගත්තෙමු.

සරල Lua ස්ක්‍රිප්ට් එකක් පෙනෙන්නේ මෙයයි:

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) නොමැතිව IOS මත ජංගම දුරකථනයකින් ලබා ගත හැකිය.

ඉලක්කය සාක්ෂාත් කර ගෙන ඇත, වෙබ් සොකට් වැඩ කරන අතර සහතිකයකට නොඅඩු ආරක්ෂිත මට්ටමක් ඇත.

මූලාශ්රය: www.habr.com

ZeroTech හි අපි Apple Safari සහ සේවාදායක සහතික වෙබ් සොකට් සමඟ සම්බන්ධ කළ ආකාරය

අදහස් එක් කරන්න ඊ-මේල් මගින් පිලිතුරු දෙන්න අවලංගු

අදහස් එක් කරන්න