LetsEncrypt ਤੋਂ ਇਲਾਵਾ ACME ਸਰਵਰਾਂ ਨਾਲ ਡੀਹਾਈਡ੍ਰੇਟਿਡ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਲੱਭਿਆ

ਸੇਬੇਸਟੀਅਨ ਕਰੌਸ ਨਿਰਧਾਰਤ ਸੇਵਾ ਨਾਲ ਅਜੀਬ ਅਸੰਗਤਤਾ ਦਾ ਸਰੋਤ ਬਾਈਪਾਸ ਸਕ੍ਰਿਪਟ ਡੀਹਾਈਡਰੇਟਿਡ, ACME ਪ੍ਰੋਟੋਕੋਲ ਰਾਹੀਂ TLS ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤੀ ਨੂੰ ਸਵੈਚਲਿਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਰੈਫਰੈਂਸ ਕਲਾਇੰਟ ਅਤੇ uacme ਦੋਵੇਂ ਬਾਈਪਾਸ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ, ਪਰ ਡੀਹਾਈਡਰੇਟ ਨਹੀਂ ਹੁੰਦੇ (ਜਾਂ ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਕੁਝ ਹੱਲਾਂ ਨਾਲ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ DNS-1 ਮੋਡ ਵਿੱਚ)।

ਕਾਰਨ ਮਾਮੂਲੀ ਨਿਕਲਿਆ: JSON ਜਵਾਬ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਪਾਰਸ ਕਰਨ ਦੀ ਬਜਾਏ, ਡੀਹਾਈਡਰੇਟਡ ਦੇ ਲੇਖਕ ਨੇ Let's Encrypt ਸੇਵਾ ਤੋਂ ਇੱਕ ਖਾਸ JSON ਆਉਟਪੁੱਟ ਦੇ ਫਾਰਮੈਟਿੰਗ ਦਾ ਸ਼ੋਸ਼ਣ ਕੀਤਾ ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਨਿਯਮਤ ਸਮੀਕਰਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਾਰਸ ਕੀਤਾ। ਪਰ ਬਾਈਪਾਸ ਨੇ ਮਿਨੀਫਾਈਡ JSON ਵਾਪਸ ਕੀਤਾ, ਸੁੰਦਰ ਢੰਗ ਨਾਲ ਫਾਰਮੈਟ ਕੀਤਾ JSON ਨਹੀਂ, ਅਤੇ ਵਰਤਿਆ ਗਿਆ ਨਿਯਮਤ ਸਮੀਕਰਨ ਇਹ ਕੰਮ ਨਹੀਂ ਕੀਤਾ। ਇਹ ਤਰੀਕਾ LetsEncrypt ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੱਦ ਨਹੀਂ ਕਰਦਾ ਜੇਕਰ ਸੇਵਾ ਭਵਿੱਖ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਚੇਤਾਵਨੀ ਦੇ ਆਪਣਾ ਜਾਰੀ ਕਰਨ ਦਾ ਫਾਰਮੈਟ ਬਦਲਦੀ ਹੈ ਜਦੋਂ ਕਿ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਧਿਕਾਰਤ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਅੰਦਰ ਰਹਿੰਦੀ ਹੈ।

ਮੁੱਦੇ 'ਤੇ ਚਰਚਾ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਬਾਹਰੀ JSON ਪਾਰਸਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਸੁਝਾਅ ਦਿੱਤਾ ਗਿਆ ਸੀ ਜਿਵੇਂ ਕਿ ਜੇਸਨ_ਪੀਪੀ ਜ jq (ਸਹੀ ਪਾਰਸਿੰਗ ਲਈ ਪਾਈਪ 'jq -r ".authorizations | .[]"' ਵਿੱਚ ਜੋੜੋ)।
ਇਸ ਪਹੁੰਚ ਦਾ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਹ ਘੱਟੋ-ਘੱਟ ਅਤੇ ਆਸਾਨੀ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਸਾਧਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਵਿਚਾਰ ਨੂੰ ਧੁੰਦਲਾ ਕਰ ਦਿੰਦਾ ਹੈ, ਨਾਲ ਹੀ ਗਲਤੀ ਸੰਭਾਲਣ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਵੀ।

ਪ੍ਰੋਜੈਕਟ ਦੇ ਲੇਖਕ ਨੂੰ ਡੀਹਾਈਡ੍ਰੇਟ ਕੀਤਾ ਗਿਆ ਸੀ (ਪ੍ਰੋਜੈਕਟ ਹਾਲ ਹੀ ਵਿੱਚ ਸੀ ਸਭ ਵਿੱਕ ਗਇਆ (ਐਪੀਲੇਅਰ ਜੀ.ਐਮ.ਬੀ.ਐਚ.) ਸਹਿਮਤ ਹੋ ਗਏਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ JSON ਪਾਰਸਿੰਗ ਇੱਕ ਵੱਡੀ ਚੁਣੌਤੀ ਹੈ, ਪਰ ਉਹ ਨਹੀਂ ਸੋਚਦਾ ਕਿ ਬਾਹਰੀ ਪਾਰਸਰ ਜੋੜਨਾ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ, ਕਿਉਂਕਿ ਸਕ੍ਰਿਪਟ ਦੀ ਇੱਕ ਮੁੱਖ ਤਾਕਤ ਇਸਦੀ ਨਿਰਭਰਤਾ ਦੀ ਘਾਟ ਹੈ। ਉਹ ਇਸ ਸਮੇਂ ਰੁੱਝਿਆ ਹੋਇਆ ਹੈ, ਪਰ ਅਗਲੇ ਕੁਝ ਦਿਨਾਂ ਵਿੱਚ ਇਸ ਮੁੱਦੇ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ। ਉਸਦੀਆਂ ਯੋਜਨਾਵਾਂ ਵਿੱਚ JSON ਪਾਰਸਰ ਨੂੰ ਦੁਬਾਰਾ ਕੰਮ ਕਰਨਾ ਜਾਂ ਮੌਜੂਦਾ ਸ਼ੈੱਲ ਪਾਰਸਰ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ। JSON.sh.

ਸਰੋਤ: opennet.ru