ਅਸੀਂ ZeroTech 'ਤੇ Apple Safari ਅਤੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟਾਂ ਨੂੰ ਵੈਬਸਾਕੇਟ ਨਾਲ ਕਿਵੇਂ ਕਨੈਕਟ ਕੀਤਾ

ਲੇਖ ਉਹਨਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੋਵੇਗਾ ਜੋ:

• ਇਹ ਜਾਣਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਕੀ ਹੈ ਅਤੇ ਸਮਝਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਮੋਬਾਈਲ ਸਫਾਰੀ 'ਤੇ ਵੈਬਸਾਕਟ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ;
• ਮੈਂ ਵੈਬ ਸੇਵਾਵਾਂ ਨੂੰ ਲੋਕਾਂ ਦੇ ਇੱਕ ਸੀਮਤ ਦਾਇਰੇ ਜਾਂ ਸਿਰਫ਼ ਆਪਣੇ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਚਾਹਾਂਗਾ;
• ਸੋਚਦਾ ਹੈ ਕਿ ਸਭ ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਦੁਆਰਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਸੰਸਾਰ ਨੂੰ ਥੋੜਾ ਹੋਰ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਸੁਰੱਖਿਅਤ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਹੈ.

ਵੈਬਸਾਕੇਟ ਦਾ ਇਤਿਹਾਸ ਲਗਭਗ 8 ਸਾਲ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ। ਪਹਿਲਾਂ, ਲੰਬੇ HTTP ਬੇਨਤੀਆਂ (ਅਸਲ ਵਿੱਚ ਜਵਾਬਾਂ) ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਧੀਆਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਸੀ: ਉਪਭੋਗਤਾ ਦੇ ਬ੍ਰਾਉਜ਼ਰ ਨੇ ਸਰਵਰ ਨੂੰ ਇੱਕ ਬੇਨਤੀ ਭੇਜੀ ਅਤੇ ਇਸਦੇ ਕੁਝ ਜਵਾਬ ਦੇਣ ਦੀ ਉਡੀਕ ਕੀਤੀ, ਜਵਾਬ ਤੋਂ ਬਾਅਦ ਇਹ ਦੁਬਾਰਾ ਜੁੜਿਆ ਅਤੇ ਉਡੀਕ ਕੀਤੀ। ਪਰ ਫਿਰ ਵੈਬਸਾਕੇਟ ਦਿਖਾਈ ਦਿੱਤੇ.



ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਅਸੀਂ ਸ਼ੁੱਧ PHP ਵਿੱਚ ਆਪਣਾ ਖੁਦ ਦਾ ਲਾਗੂਕਰਨ ਵਿਕਸਿਤ ਕੀਤਾ ਹੈ, ਜੋ ਕਿ https ਬੇਨਤੀਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਲਿੰਕ ਲੇਅਰ ਹੈ। ਕੁਝ ਸਮਾਂ ਪਹਿਲਾਂ, ਲਗਭਗ ਸਾਰੇ ਵੈਬ ਸਰਵਰਾਂ ਨੇ https ਅਤੇ ਸਹਾਇਤਾ ਕੁਨੈਕਸ਼ਨ: ਅੱਪਗ੍ਰੇਡ 'ਤੇ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀਆਂ ਸਿੱਖ ਲਈਆਂ ਹਨ।

ਜਦੋਂ ਇਹ ਵਾਪਰਿਆ, ਵੈਬਸਾਕੇਟ ਐਸਪੀਏ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਲਗਭਗ ਡਿਫੌਲਟ ਸੇਵਾ ਬਣ ਗਈ, ਕਿਉਂਕਿ ਸਰਵਰ ਦੀ ਪਹਿਲਕਦਮੀ 'ਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਸਮੱਗਰੀ ਪ੍ਰਦਾਨ ਕਰਨਾ ਕਿੰਨਾ ਸੁਵਿਧਾਜਨਕ ਹੈ (ਕਿਸੇ ਹੋਰ ਉਪਭੋਗਤਾ ਤੋਂ ਸੁਨੇਹਾ ਭੇਜਣਾ ਜਾਂ ਚਿੱਤਰ, ਦਸਤਾਵੇਜ਼, ਪੇਸ਼ਕਾਰੀ ਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਡਾਊਨਲੋਡ ਕਰਨਾ ਕਿ ਕੋਈ ਹੋਰ ਇਸ ਵੇਲੇ ਸੰਪਾਦਨ ਕਰ ਰਿਹਾ ਹੈ)।

ਹਾਲਾਂਕਿ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਕਾਫ਼ੀ ਸਮੇਂ ਤੋਂ ਆਲੇ-ਦੁਆਲੇ ਹੈ, ਇਹ ਅਜੇ ਵੀ ਮਾੜਾ ਸਹਿਯੋਗੀ ਬਣਿਆ ਹੋਇਆ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇਸ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਅਤੇ (ਸੰਭਵ ਤੌਰ 'ਤੇ :slightly_smiling_face: ) ਇਸ ਲਈ IOS ਬ੍ਰਾਊਜ਼ਰ (ਸਫਾਰੀ ਨੂੰ ਛੱਡ ਕੇ ਸਾਰੇ) ਇਸਨੂੰ ਵਰਤਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹਨ ਅਤੇ ਸਥਾਨਕ ਸਰਟੀਫਿਕੇਟ ਸਟੋਰ ਤੋਂ ਇਸਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਲੌਗਇਨ/ਪਾਸ ਜਾਂ ssh ਕੁੰਜੀਆਂ ਜਾਂ ਫਾਇਰਵਾਲ ਰਾਹੀਂ ਜ਼ਰੂਰੀ ਪੋਰਟਾਂ ਨੂੰ ਬੰਦ ਕਰਨ ਦੇ ਮੁਕਾਬਲੇ ਸਰਟੀਫਿਕੇਟਾਂ ਦੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਹਨ। ਪਰ ਇਹ ਇਸ ਬਾਰੇ ਨਹੀਂ ਹੈ।

ਆਈਓਐਸ 'ਤੇ, ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਸਥਾਪਤ ਕਰਨ ਦੀ ਵਿਧੀ ਕਾਫ਼ੀ ਸਰਲ ਹੈ (ਬਿਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਨਹੀਂ), ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਿਰਦੇਸ਼ਾਂ ਦੇ ਅਨੁਸਾਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਇੰਟਰਨੈਟ ਤੇ ਹਨ ਅਤੇ ਜੋ ਸਿਰਫ ਸਫਾਰੀ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਉਪਲਬਧ ਹਨ. ਬਦਕਿਸਮਤੀ ਨਾਲ, Safari ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਵੈੱਬ ਸਾਕਟਾਂ ਲਈ ਕਲਾਇੰਟ Сert ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ, ਪਰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਅਜਿਹੇ ਸਰਟੀਫਿਕੇਟ ਕਿਵੇਂ ਬਣਾਉਣੇ ਹਨ, ਇਸ ਬਾਰੇ ਬਹੁਤ ਸਾਰੀਆਂ ਹਦਾਇਤਾਂ ਹਨ, ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ।

ਵੈੱਬਸਾਕੇਟਾਂ ਨੂੰ ਸਮਝਣ ਲਈ, ਅਸੀਂ ਹੇਠ ਦਿੱਤੀ ਯੋਜਨਾ ਦੀ ਵਰਤੋਂ ਕੀਤੀ: ਸਮੱਸਿਆ/ਕਲਪਨਾ/ਹੱਲ।

ਸਮੱਸਿਆ: ਆਈਓਐਸ ਅਤੇ ਹੋਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਸਫਾਰੀ ਮੋਬਾਈਲ ਬ੍ਰਾਊਜ਼ਰ 'ਤੇ ਇੱਕ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਦੁਆਰਾ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਸਰੋਤਾਂ ਲਈ ਬੇਨਤੀਆਂ ਨੂੰ ਪ੍ਰੌਕਸੀ ਕਰਨ ਵੇਲੇ ਵੈਬ ਸਾਕਟਾਂ ਲਈ ਕੋਈ ਸਮਰਥਨ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਸਰਟੀਫਿਕੇਟ ਸਹਾਇਤਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ ਹੈ।

ਕਲਪਨਾ:

1. ਅਜਿਹੇ ਅਪਵਾਦ ਨੂੰ ਅੰਦਰੂਨੀ/ਬਾਹਰੀ ਪ੍ਰੌਕਸੀ ਸਰੋਤਾਂ ਦੇ ਵੈਬਸਾਕਟਾਂ ਲਈ ਸਰਟੀਫਿਕੇਟ (ਇਹ ਜਾਣਦੇ ਹੋਏ ਕਿ ਕੋਈ ਨਹੀਂ ਹੋਵੇਗਾ) ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ।
2. ਵੈਬਸਾਕੇਟ ਲਈ, ਤੁਸੀਂ ਅਸਥਾਈ ਸੈਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਵਿਲੱਖਣ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਬਚਾਅਯੋਗ ਕਨੈਕਸ਼ਨ ਬਣਾ ਸਕਦੇ ਹੋ ਜੋ ਇੱਕ ਆਮ (ਗੈਰ-ਵੈਬਸਾਕੇਟ) ਬ੍ਰਾਊਜ਼ਰ ਬੇਨਤੀ ਦੇ ਦੌਰਾਨ ਉਤਪੰਨ ਹੁੰਦੇ ਹਨ।
3. ਅਸਥਾਈ ਸੈਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰੌਕਸੀ ਵੈੱਬ ਸਰਵਰ (ਸਿਰਫ਼ ਬਿਲਟ-ਇਨ ਮੋਡਿਊਲ ਅਤੇ ਫੰਕਸ਼ਨਾਂ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
4. ਅਸਥਾਈ ਸੈਸ਼ਨ ਟੋਕਨ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਕੀਤੇ ਅਪਾਚੇ ਮੋਡੀਊਲ ਵਜੋਂ ਲਾਗੂ ਕੀਤੇ ਜਾ ਚੁੱਕੇ ਹਨ।
5. ਅਸਥਾਈ ਸੈਸ਼ਨ ਟੋਕਨਾਂ ਨੂੰ ਤਾਰਕਿਕ ਤੌਰ 'ਤੇ ਇੰਟਰੈਕਸ਼ਨ ਢਾਂਚੇ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਲਾਗੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਸਥਿਤੀ।

ਉਦੇਸ਼: ਸੇਵਾਵਾਂ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਪ੍ਰਬੰਧਨ ਬਿਨਾਂ ਵਾਧੂ ਪ੍ਰੋਗਰਾਮਾਂ (ਜਿਵੇਂ ਕਿ 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 ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ. ਇਹ ਅਜੇ ਵੀ ਡਰਾਫਟ ਵਿੱਚ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨਿਰਮਾਤਾ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਇਸਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ #info about tls1.3 http2 ਪੋਸਟ ਹੈਂਡਸ਼ੇਕ (ਹੁਣ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ) RFC 8740 ਲਾਗੂ ਕਰੋ "HTTP/1.3 ਦੇ ਨਾਲ TLS 2 ਦੀ ਵਰਤੋਂ ਕਰਨਾ";
• ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਕਿਵੇਂ ਇਕਮੁੱਠ ਕਰਨਾ ਹੈ।

b) ਇੱਕ ਬੁਨਿਆਦੀ ਪੱਧਰ 'ਤੇ, ਬਿਨਾਂ ਸਰਟੀਫਿਕੇਟ ਦੇ 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 ਬਾਰੇ ਲੇਖ ਵਿੱਚ ਪਾਈ ਜਾ ਸਕਦੀ ਹੈ: ਅਪਾਚੇ ਸਰਵਰ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣੀਕਰਨ

ਦੋਵਾਂ ਵਿਕਲਪਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ, ਵਿਕਲਪ "b" ਨੂੰ ਇਸਦੀ ਬਹੁਪੱਖੀਤਾ ਅਤੇ http2 ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਅਨੁਕੂਲਤਾ ਲਈ ਚੁਣਿਆ ਗਿਆ ਸੀ।

ਇਸ ਪਰਿਕਲਪਨਾ ਦੀ ਤਸਦੀਕ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਇਸ ਨੇ ਸੰਰਚਨਾ ਦੇ ਨਾਲ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਯੋਗ ਕੀਤੇ; ਹੇਠਾਂ ਦਿੱਤੇ ਡਿਜ਼ਾਈਨ ਦੀ ਜਾਂਚ ਕੀਤੀ ਗਈ:

if = ਲੋੜ = ਮੁੜ ਲਿਖੋ

• ਅਪਾਚੇ ਕੋਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ
• ਅਪਾਚੇ HTTP ਸਰਵਰ ਵਿੱਚ ਸਮੀਕਰਨ

ਨਤੀਜਾ ਹੇਠ ਦਿੱਤੇ ਬੁਨਿਆਦੀ ਡਿਜ਼ਾਈਨ ਹੈ:

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 ਦੀ ਬਜਾਏ) ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਗੈਰ-ਮੌਜੂਦ ਸਰਟੀਫਿਕੇਟ ਮਾਲਕ ਸ਼ਾਮਲ ਕਰਨਾ ਪਿਆ, ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹੋਰ ਵੇਰਵੇ:

ਅਪਾਚੇ ਮੋਡੀਊਲ 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. ਅਸਥਾਈ ਸੈਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰੌਕਸੀ ਵੈੱਬ ਸਰਵਰ (ਸਿਰਫ਼ ਬਿਲਟ-ਇਨ ਮੋਡੀਊਲ ਅਤੇ ਫੰਕਸ਼ਨਾਂ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਪਤਾ ਲਗਾਇਆ ਹੈ, ਅਪਾਚੇ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਮੁੱਖ ਕਾਰਜਕੁਸ਼ਲਤਾ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਕੰਡੀਸ਼ਨਲ ਕੰਸਟ੍ਰਕਟ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ, ਸਾਨੂੰ ਸਾਡੀ ਜਾਣਕਾਰੀ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਸਾਧਨਾਂ ਦੀ ਲੋੜ ਹੈ ਜਦੋਂ ਇਹ ਉਪਭੋਗਤਾ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਹੈ, ਇਸ ਲਈ ਅਸੀਂ ਇਹ ਸਥਾਪਿਤ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਸਟੋਰ ਕਰਨਾ ਹੈ ਅਤੇ ਕਿਉਂ, ਅਤੇ ਅਸੀਂ ਕਿਹੜੇ ਬਿਲਟ-ਇਨ ਫੰਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ:

• ਸਾਨੂੰ ਇੱਕ ਟੋਕਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਆਸਾਨੀ ਨਾਲ ਡੀਕੋਡ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਸਾਨੂੰ ਇੱਕ ਟੋਕਨ ਦੀ ਲੋੜ ਹੈ ਜਿਸ ਵਿੱਚ ਅਪ੍ਰਚਲਿਤਤਾ ਬਣੀ ਹੋਈ ਹੈ ਅਤੇ ਸਰਵਰ 'ਤੇ ਅਪ੍ਰਚਲਿਤਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਯੋਗਤਾ ਹੈ।
• ਸਾਨੂੰ ਇੱਕ ਟੋਕਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਸਰਟੀਫਿਕੇਟ ਦੇ ਮਾਲਕ ਨਾਲ ਜੁੜਿਆ ਹੋਵੇਗਾ।

ਇਸ ਲਈ ਇੱਕ ਹੈਸ਼ਿੰਗ ਫੰਕਸ਼ਨ, ਇੱਕ ਨਮਕ, ਅਤੇ ਟੋਕਨ ਦੀ ਉਮਰ ਲਈ ਇੱਕ ਮਿਤੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਦਸਤਾਵੇਜ਼ ਦੇ ਆਧਾਰ 'ਤੇ ਅਪਾਚੇ 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 token json two factor auth.

• JSON ਵੈੱਬ ਟੋਕਨਾਂ 'ਤੇ ਆਧਾਰਿਤ ਟੋਕਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣੀਕਰਨ
• ਅਪਾਚੇ ਦੋ-ਫੈਕਟਰ (2FA) ਪ੍ਰਮਾਣਿਕਤਾ
• ਅਪਾਚੇ ਵਿੱਚ ਦੋ-ਫੈਕਟਰ ਪ੍ਰਮਾਣਿਕਤਾ ਕਿਵੇਂ ਸ਼ਾਮਲ ਕਰੀਏ
• ਇੱਕ ਸਧਾਰਨ ਮੋਡੀਊਲ ਸਥਾਪਨਾ ਨਾਲ ਆਪਣੇ ਅਪਾਚੇ ਉਦਾਹਰਨ ਲਈ ਦੋ-ਕਾਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਲਿਆਓ

ਹਾਂ, ਇੱਥੇ ਤਿਆਰ ਮੋਡੀਊਲ ਹਨ, ਪਰ ਉਹ ਸਾਰੇ ਖਾਸ ਕਿਰਿਆਵਾਂ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ ਅਤੇ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਵਾਧੂ ਕੂਕੀਜ਼ ਦੇ ਰੂਪ ਵਿੱਚ ਕਲਾਤਮਕ ਚੀਜ਼ਾਂ ਹਨ। ਭਾਵ, ਕੁਝ ਸਮੇਂ ਲਈ ਨਹੀਂ।
ਸਾਨੂੰ ਖੋਜ ਕਰਨ ਵਿੱਚ ਪੰਜ ਘੰਟੇ ਲੱਗ ਗਏ, ਜਿਸ ਦਾ ਕੋਈ ਠੋਸ ਨਤੀਜਾ ਨਹੀਂ ਨਿਕਲਿਆ।

5. ਅਸਥਾਈ ਸੈਸ਼ਨ ਟੋਕਨਾਂ ਨੂੰ ਪਰਸਪਰ ਕ੍ਰਿਆਵਾਂ ਦੇ ਢਾਂਚੇ ਨੂੰ ਤਰਕ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕਰਕੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਤਿਆਰ ਮੋਡੀਊਲ ਬਹੁਤ ਗੁੰਝਲਦਾਰ ਹਨ, ਕਿਉਂਕਿ ਸਾਨੂੰ ਸਿਰਫ ਕੁਝ ਫੰਕਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਕਿਹਾ ਜਾ ਰਿਹਾ ਹੈ, ਮਿਤੀ ਦੇ ਨਾਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਅਪਾਚੇ ਦੇ ਬਿਲਟ-ਇਨ ਫੰਕਸ਼ਨ ਭਵਿੱਖ ਤੋਂ ਇੱਕ ਮਿਤੀ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਅਪ੍ਰਚਲਿਤਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਸਮੇਂ ਬਿਲਟ-ਇਨ ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਕੋਈ ਗਣਿਤਿਕ ਜੋੜ/ਘਟਾਓ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਭਾਵ, ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਲਿਖ ਸਕਦੇ:

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

ਤੁਸੀਂ ਸਿਰਫ਼ ਦੋ ਨੰਬਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਸਕਦੇ ਹੋ।

ਸਫਾਰੀ ਸਮੱਸਿਆ ਲਈ ਹੱਲ ਲੱਭਦੇ ਹੋਏ, ਮੈਨੂੰ ਇੱਕ ਦਿਲਚਸਪ ਲੇਖ ਮਿਲਿਆ: ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਹੋਮ ਅਸਿਸਟੈਂਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨਾ (ਸਫਾਰੀ/ਆਈਓਐਸ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ)
ਇਹ Nginx ਲਈ ਲੁਆ ਵਿੱਚ ਕੋਡ ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੋ ਕਿ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਰਚਨਾ ਦੇ ਉਸ ਹਿੱਸੇ ਦੇ ਤਰਕ ਨੂੰ ਦੁਹਰਾਉਂਦਾ ਹੈ ਜੋ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲਾਗੂ ਕੀਤਾ ਹੈ, ਹੈਸ਼ਿੰਗ ਲਈ hmac ਸਾਲਟਿੰਗ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਦੇ ਅਪਵਾਦ ਦੇ ਨਾਲ ( ਇਹ ਅਪਾਚੇ ਵਿੱਚ ਨਹੀਂ ਪਾਇਆ ਗਿਆ ਸੀ)।

ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਕਿ ਲੂਆ ਸਪੱਸ਼ਟ ਤਰਕ ਵਾਲੀ ਭਾਸ਼ਾ ਹੈ, ਅਤੇ ਅਪਾਚੇ ਲਈ ਕੁਝ ਸਧਾਰਨ ਕਰਨਾ ਸੰਭਵ ਹੈ:

• LuaHookAccessChecker ਡਾਇਰੈਕਟਿਵ
• UnsetEnv ਡਾਇਰੈਕਟਿਵ

Nginx ਅਤੇ Apache ਨਾਲ ਅੰਤਰ ਦਾ ਅਧਿਐਨ ਕਰਨ ਤੋਂ ਬਾਅਦ:

• modules_lua
• lua_load_resty_core

ਅਤੇ ਲੁਆ ਭਾਸ਼ਾ ਨਿਰਮਾਤਾ ਤੋਂ ਉਪਲਬਧ ਫੰਕਸ਼ਨ:
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 ਤੋਂ ਇਸ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਪਹੁੰਚ ਜਾਂਚਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਕਿਰਿਆਸ਼ੀਲ ਹੋਵੇਗਾ।

ਸਰੋਤ ਨਾਲ ਲਿੰਕ ਚਿੱਤਰ ਨੂੰ.

ਇਕ ਹੋਰ ਚੀਜ਼.

ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦਾ ਕਿ ਅਪਾਚੇ (ਸ਼ਾਇਦ Nginx ਵੀ) ਸੰਰਚਨਾ ਵਿੱਚ ਨਿਰਦੇਸ਼ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ ਲਿਖੇ ਗਏ ਹਨ, ਕਿਉਂਕਿ ਅੰਤ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਨੂੰ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਬੇਨਤੀ ਦੇ ਕ੍ਰਮ ਦੇ ਅਧਾਰ ਤੇ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਜਾਵੇਗਾ, ਜੋ ਕਿ ਪ੍ਰਕਿਰਿਆ ਲਈ ਯੋਜਨਾ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ. ਲੂਆ ਸਕ੍ਰਿਪਟਾਂ.

ਸੰਪੂਰਨਤਾ:

ਲਾਗੂ ਕਰਨ ਤੋਂ ਬਾਅਦ ਦਿਖਾਈ ਦੇਣ ਵਾਲੀ ਸਥਿਤੀ (ਟੀਚਾ):
ਸੇਵਾਵਾਂ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਪ੍ਰਬੰਧਨ IOS 'ਤੇ ਮੋਬਾਈਲ ਫ਼ੋਨ ਤੋਂ ਬਿਨਾਂ ਵਾਧੂ ਪ੍ਰੋਗਰਾਮਾਂ (VPN), ਯੂਨੀਫਾਈਡ ਅਤੇ ਸੁਰੱਖਿਅਤ ਉਪਲਬਧ ਹੈ।

ਟੀਚਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਵੈਬ ਸਾਕਟ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਸੁਰੱਖਿਆ ਦਾ ਪੱਧਰ ਇੱਕ ਸਰਟੀਫਿਕੇਟ ਤੋਂ ਘੱਟ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com