వ్యాసం వారికి ఉపయోగపడుతుంది:
- క్లయింట్ సెర్ట్ అంటే ఏమిటో తెలుసు మరియు మొబైల్ సఫారిలో వెబ్సాకెట్లు ఎందుకు అవసరమో అర్థం చేసుకుంటుంది;
- నేను పరిమిత వ్యక్తుల సర్కిల్‌కు లేదా నాకు మాత్రమే వెబ్ సేవలను ప్రచురించాలనుకుంటున్నాను;
- ప్రతిదీ ఇప్పటికే ఎవరైనా పూర్తి చేసిందని మరియు ప్రపంచాన్ని మరింత సౌకర్యవంతంగా మరియు సురక్షితంగా మార్చాలనుకుంటున్నారని భావిస్తాడు.
వెబ్సాకెట్ల చరిత్ర సుమారు 8 సంవత్సరాల క్రితం ప్రారంభమైంది. గతంలో, పద్ధతులు సుదీర్ఘ http అభ్యర్థనల రూపంలో ఉపయోగించబడ్డాయి (వాస్తవానికి ప్రతిస్పందనలు): వినియోగదారు యొక్క బ్రౌజర్ సర్వర్‌కు అభ్యర్థనను పంపింది మరియు ప్రతిస్పందన తర్వాత అది మళ్లీ కనెక్ట్ అయ్యి వేచి ఉంది. కానీ వెబ్సాకెట్లు కనిపించాయి.
కొన్ని సంవత్సరాల క్రితం, ఇది లింక్ లేయర్ అయినందున https అభ్యర్థనలను ఉపయోగించలేని స్వచ్ఛమైన PHPలో మా స్వంత అమలును మేము అభివృద్ధి చేసాము. కొంతకాలం క్రితం, దాదాపు అన్ని వెబ్ సర్వర్‌లు https ద్వారా ప్రాక్సీ అభ్యర్థనలను నేర్చుకున్నాయి మరియు కనెక్షన్:అప్‌గ్రేడ్‌కు మద్దతు ఇస్తున్నాయి.
ఇది జరిగినప్పుడు, వెబ్సాకెట్లు SPA అప్లికేషన్‌లకు దాదాపు డిఫాల్ట్ సేవగా మారాయి, ఎందుకంటే సర్వర్ చొరవతో వినియోగదారుకు కంటెంట్‌ను అందించడం ఎంత సౌకర్యవంతంగా ఉంటుంది (మరొక వినియోగదారు నుండి సందేశాన్ని ప్రసారం చేయండి లేదా చిత్రం, పత్రం, ప్రదర్శన యొక్క కొత్త సంస్కరణను డౌన్‌లోడ్ చేయండి ప్రస్తుతం వేరొకరు ఎడిట్ చేస్తున్నారు) .
క్లయింట్ సర్టిఫికేట్ చాలా కాలంగా ఉన్నప్పటికీ, ఇది ఇప్పటికీ పేలవంగా మద్దతు ఇవ్వబడుతోంది, ఎందుకంటే దానిని దాటవేయడానికి ప్రయత్నిస్తున్నప్పుడు ఇది చాలా సమస్యలను సృష్టిస్తుంది. మరియు (బహుశా :slightly_smiling_face: ) అందుకే IOS బ్రౌజర్‌లు (సఫారి మినహా అన్నీ) దీన్ని ఉపయోగించడానికి మరియు స్థానిక సర్టిఫికేట్ స్టోర్ నుండి అభ్యర్థించడానికి ఇష్టపడవు. లాగిన్/పాస్ లేదా ssh కీలు లేదా ఫైర్‌వాల్ ద్వారా అవసరమైన పోర్ట్‌లను మూసివేయడం వంటి వాటితో పోలిస్తే సర్టిఫికెట్‌లు అనేక ప్రయోజనాలను కలిగి ఉంటాయి. కానీ ఇది దాని గురించి కాదు.
IOS లో, సర్టిఫికేట్‌ను ఇన్‌స్టాల్ చేసే విధానం చాలా సులభం (ప్రత్యేకతలు లేకుండా కాదు), కానీ సాధారణంగా ఇది సూచనల ప్రకారం జరుగుతుంది, వీటిలో ఇంటర్నెట్‌లో చాలా ఉన్నాయి మరియు ఇవి సఫారి బ్రౌజర్‌కు మాత్రమే అందుబాటులో ఉన్నాయి. దురదృష్టవశాత్తూ, వెబ్ సాకెట్ల కోసం క్లయింట్ సెర్ట్‌ను ఎలా ఉపయోగించాలో Safariకి తెలియదు, అయితే అటువంటి ప్రమాణపత్రాన్ని ఎలా సృష్టించాలో ఇంటర్నెట్‌లో అనేక సూచనలు ఉన్నాయి, కానీ ఆచరణలో ఇది సాధించలేనిది.
వెబ్‌సాకెట్‌లను అర్థం చేసుకోవడానికి, మేము ఈ క్రింది ప్లాన్‌ని ఉపయోగించాము: సమస్య/పరికల్పన/పరిష్కారం.
సమస్య: IOS మరియు సర్టిఫికేట్ మద్దతును ప్రారంభించిన ఇతర అప్లికేషన్‌ల కోసం Safari మొబైల్ బ్రౌజర్‌లో క్లయింట్ ప్రమాణపత్రం ద్వారా రక్షించబడిన వనరులకు అభ్యర్థనలను ప్రాక్సీ చేస్తున్నప్పుడు వెబ్ సాకెట్‌లకు మద్దతు ఉండదు.
పరికల్పనలు:
- అంతర్గత/బాహ్య ప్రాక్సీడ్ వనరుల వెబ్‌సాకెట్‌లకు సర్టిఫికెట్‌లను (ఏదీ ఉండదని తెలిసి) ఉపయోగించడానికి అటువంటి మినహాయింపును కాన్ఫిగర్ చేయడం సాధ్యపడుతుంది.
- వెబ్సాకెట్ల కోసం, మీరు సాధారణ (వెబ్‌సాకెట్ కాని) బ్రౌజర్ అభ్యర్థన సమయంలో ఉత్పత్తి చేయబడిన తాత్కాలిక సెషన్‌లను ఉపయోగించి ప్రత్యేకమైన, సురక్షితమైన మరియు రక్షణాత్మక కనెక్షన్‌ని చేయవచ్చు.
- ఒక ప్రాక్సీ వెబ్ సర్వర్ (అంతర్నిర్మిత మాడ్యూల్స్ మరియు ఫంక్షన్లు మాత్రమే) ఉపయోగించి తాత్కాలిక సెషన్‌లను అమలు చేయవచ్చు.
- తాత్కాలిక సెషన్ టోకెన్లు ఇప్పటికే రెడీమేడ్ అపాచీ మాడ్యూల్స్‌గా అమలు చేయబడ్డాయి.
- తాత్కాలిక సెషన్ టోకెన్‌లను తార్కికంగా పరస్పర నిర్మాణాన్ని రూపొందించడం ద్వారా అమలు చేయవచ్చు.
అమలు తర్వాత కనిపించే స్థితి.
పని యొక్క లక్ష్యం: సేవల నిర్వహణ మరియు అవస్థాపన IOSలో మొబైల్ ఫోన్ నుండి అదనపు ప్రోగ్రామ్‌లు (VPN వంటివి) లేకుండా ఏకీకృతంగా మరియు సురక్షితంగా ఉండాలి.
అదనపు లక్ష్యం: మొబైల్ ఇంటర్నెట్‌లో కంటెంట్‌ను వేగంగా డెలివరీ చేయడంతో సమయం మరియు వనరులు/ఫోన్ ట్రాఫిక్ (వెబ్ సాకెట్లు లేని కొన్ని సేవలు అనవసరమైన అభ్యర్థనలను సృష్టిస్తాయి) ఆదా చేస్తాయి.
ఎలా తనిఖీ చేయాలి?
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>
యాక్సెస్ స్థాయిని మార్చండి.
ఈ పద్ధతి క్రింది సూక్ష్మ నైపుణ్యాలను కలిగి ఉంది:
- ప్రాక్సీడ్ రిసోర్స్‌కి అభ్యర్థన తర్వాత సర్టిఫికేట్ ధృవీకరణ జరుగుతుంది, అనగా పోస్ట్ అభ్యర్థన హ్యాండ్‌షేక్. దీనర్థం ప్రాక్సీ మొదట లోడ్ చేయబడి, ఆపై రక్షిత సేవకు అభ్యర్థనను కట్ చేస్తుంది. ఇది చెడ్డది, కానీ క్లిష్టమైనది కాదు;
- http2 ప్రోటోకాల్‌లో. ఇది ఇప్పటికీ డ్రాఫ్ట్‌లో ఉంది మరియు బ్రౌజర్ తయారీదారులకు దీన్ని ఎలా అమలు చేయాలో తెలియదు #info about tls1.3 http2 పోస్ట్ హ్యాండ్‌షేక్ (ఇప్పుడు పని చేయడం లేదు) ;
- ఈ ప్రాసెసింగ్‌ను ఎలా ఏకీకృతం చేయాలో స్పష్టంగా లేదు.
బి) ప్రాథమిక స్థాయిలో, ప్రమాణపత్రం లేకుండా 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 గురించిన మరింత వివరణాత్మక సమాచారాన్ని వ్యాసంలో చూడవచ్చు:
రెండు ఎంపికలు పరీక్షించబడ్డాయి, 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కి బదులుగా) రూపంలో డాక్యుమెంటేషన్‌లోని మరిన్ని వివరాలు రూపంలో ఉనికిలో లేని సర్టిఫికేట్ యజమానిని జోడించాల్సి వచ్చింది:
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. ఒక ప్రాక్సీ వెబ్ సర్వర్ (అంతర్నిర్మిత మాడ్యూల్స్ మరియు ఫంక్షన్లు మాత్రమే) ఉపయోగించి తాత్కాలిక సెషన్‌లను అమలు చేయవచ్చు.
మేము ఇంతకు ముందే కనుగొన్నట్లుగా, అపాచీలో చాలా కోర్ ఫంక్షనాలిటీ ఉంది, ఇది షరతులతో కూడిన నిర్మాణాలను సృష్టించడానికి మిమ్మల్ని అనుమతిస్తుంది. అయినప్పటికీ, వినియోగదారు బ్రౌజర్‌లో ఉన్నప్పుడు మా సమాచారాన్ని రక్షించడానికి మాకు మార్గాలు అవసరం, కాబట్టి మేము ఏమి నిల్వ చేయాలి మరియు ఎందుకు నిల్వ చేయాలి మరియు మేము ఏ అంతర్నిర్మిత ఫంక్షన్‌లను ఉపయోగిస్తాము:
- మాకు సులభంగా డీకోడ్ చేయలేని టోకెన్ అవసరం.
- మాకు వాడుకలో ఉన్న టోకెన్ అవసరం మరియు సర్వర్‌లో వాడుకలో లేని వాటిని తనిఖీ చేసే సామర్థ్యాన్ని కలిగి ఉంటుంది.
- మాకు సర్టిఫికేట్ యజమానితో అనుబంధించబడే టోకెన్ అవసరం.
దీనికి హ్యాషింగ్ ఫంక్షన్, ఉప్పు మరియు టోకెన్‌కు వయస్సు రావడానికి తేదీ అవసరం. డాక్యుమెంటేషన్ ఆధారంగా మేము షా1 మరియు %{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 టోకెన్ json రెండు కారకాల ప్రమాణీకరణ
అవును, రెడీమేడ్ మాడ్యూల్స్ ఉన్నాయి, కానీ అవన్నీ నిర్దిష్ట చర్యలతో ముడిపడి ఉంటాయి మరియు సెషన్ మరియు అదనపు కుక్కీలను ప్రారంభించే రూపంలో కళాఖండాలను కలిగి ఉంటాయి. అంటే కాసేపు కాదు.
శోధించడానికి మాకు ఐదు గంటలు పట్టింది, ఇది ఖచ్చితమైన ఫలితాన్ని ఇవ్వలేదు.
5. తార్కికంగా పరస్పర చర్యల నిర్మాణాన్ని రూపొందించడం ద్వారా తాత్కాలిక సెషన్ టోకెన్‌లను అమలు చేయవచ్చు.
రెడీమేడ్ మాడ్యూల్స్ చాలా క్లిష్టంగా ఉంటాయి, ఎందుకంటే మనకు కొన్ని ఫంక్షన్లు మాత్రమే అవసరం.
ఇలా చెప్పుకుంటూ పోతే, తేదీకి సంబంధించిన సమస్య ఏమిటంటే, Apache యొక్క అంతర్నిర్మిత ఫంక్షన్లు భవిష్యత్తు నుండి తేదీని రూపొందించడానికి అనుమతించవు మరియు వాడుకలో లేని వాటి కోసం తనిఖీ చేస్తున్నప్పుడు అంతర్నిర్మిత ఫంక్షన్‌లలో గణిత శాస్త్ర సంకలనం/వ్యవకలనం ఉండదు.
అంటే, మీరు వ్రాయలేరు:
(%{env:zt-cert-date} + 30) > %{DATE}
మీరు రెండు సంఖ్యలను మాత్రమే సరిపోల్చగలరు.
సఫారి సమస్యకు పరిష్కారం కోసం వెతుకుతున్నప్పుడు, నేను ఒక ఆసక్తికరమైన కథనాన్ని కనుగొన్నాను:
ఇది Nginx కోసం లువాలోని కోడ్ యొక్క ఉదాహరణను వివరిస్తుంది మరియు హ్యాషింగ్ కోసం hmac సాల్టింగ్ పద్ధతిని ఉపయోగించడం మినహా, మేము ఇప్పటికే అమలు చేసిన కాన్ఫిగరేషన్ యొక్క ఆ భాగం యొక్క తర్కాన్ని చాలా పునరావృతం చేస్తుంది ( ఇది అపాచీలో కనుగొనబడలేదు).
లువా అనేది స్పష్టమైన తర్కంతో కూడిన భాష అని స్పష్టమైంది మరియు అపాచీ కోసం సరళంగా ఏదైనా చేయడం సాధ్యమే:
Nginx మరియు Apacheతో వ్యత్యాసాన్ని అధ్యయనం చేసిన తర్వాత:
మరియు Lua భాషా తయారీదారు నుండి అందుబాటులో ఉన్న విధులు:
ప్రస్తుత తేదీతో పోల్చడానికి భవిష్యత్తు నుండి తేదీని సెట్ చేయడానికి చిన్న Lua ఫైల్‌లో 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 నుండి ఈ సమాచారం ఆధారంగా యాక్సెస్ తనిఖీల తర్వాత మాత్రమే యాక్టివేట్ చేయబడుతుంది.
మూలానికి లింక్.
ఇంకో విషయం.
సాధారణంగా, అపాచీ (బహుశా Nginx) కాన్ఫిగరేషన్‌లో ఆదేశాలు ఏ క్రమంలో వ్రాయబడ్డాయి అనేది పట్టింపు లేదు, ఎందుకంటే చివరికి ప్రతిదీ వినియోగదారు అభ్యర్థన యొక్క క్రమం ఆధారంగా క్రమబద్ధీకరించబడుతుంది, ఇది ప్రాసెసింగ్ కోసం స్కీమ్‌కు అనుగుణంగా ఉంటుంది. లువా స్క్రిప్ట్‌లు.
పూర్తి:
అమలు తర్వాత కనిపించే స్థితి (లక్ష్యం):
సేవలు మరియు మౌలిక సదుపాయాల నిర్వహణ అనేది IOSలో మొబైల్ ఫోన్ నుండి అదనపు ప్రోగ్రామ్‌లు (VPN) లేకుండా ఏకీకృత మరియు సురక్షితమైనది.
లక్ష్యం సాధించబడింది, వెబ్ సాకెట్లు పని చేస్తాయి మరియు ప్రమాణపత్రం కంటే తక్కువ భద్రత స్థాయిని కలిగి ఉంటాయి.
మూలం: www.habr.com