ਤੁਹਾਡਾ Magento ਰੀਡਾਇਰੈਕਟ ਲੂਪ ਸ਼ਾਇਦ VPN ਨਹੀਂ ਹੈ

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

302 ਦੱਸਦਾ ਹੈ ਕਿੱਥੇ, ਕਿਉਂ ਨਹੀਂ

ਐਕਸੈਸ ਲੌਗ ਦੀ ਐਂਟਰੀ ਬੇਨਤੀ, ਸਥਿਤੀ ਅਤੇ ਆਕਾਰ ਦਰਜ ਕਰਦੀ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ Location ਹੈਡਰ ਛੱਡ ਦਿੰਦੀ ਹੈ। ਇੱਕ ਰੀਡਾਇਰੈਕਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਮ ਹੋ ਸਕਦਾ ਹੈ: ਪ੍ਰਮਾਣਿਕ ਹੋਸਟਨਾਮ, ਆਖਰੀ ਸਲੈਸ਼ ਦਾ ਸਧਾਰਨੀਕਰਨ, HTTPS 'ਤੇ ਬਦਲਾਅ। ਤੁਹਾਨੂੰ ਕ੍ਰਮ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇੱਕ ਛਾਲ ਅਤੇ ਇੱਕ ਲੂਪ ਵੱਖਰੀਆਂ ਖਰਾਬੀਆਂ ਹਨ, ਵੱਖਰੇ ਮਾਲਕਾਂ ਨਾਲ। ਸਕੀਮਾਂ ਵਿਚਕਾਰ ਦੁਹਰਾਉਂਦੀਆਂ ਛਾਲਾਂ URL ਅਤੇ ਸਕੀਮ ਸੰਭਾਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀਆਂ ਹਨ। ਪਰ ਅਜਿਹੇ ਨਾਮ ਵੱਲ ਛਾਲ ਜੋ ਬ੍ਰਾਊਜ਼ਰ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਬਿਲਕੁਲ ਕਿਸੇ ਹੋਰ ਥਾਂ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ VPN ਬਾਰੇ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਟਨਲ ਇੱਕ ਰਾਹ ਹੈ; ਰੀਡਾਇਰੈਕਟ ਉਹ ਹਦਾਇਤ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਲਿਖੀ।

ਲੌਗ ਦੀ ਲਾਈਨ ਨਹੀਂ, ਚੇਨ ਫੜੋ

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

ਉਹ ਰਿਕਾਰਡ ਨਿੱਜੀ ਰੱਖੋ। URL ਸੈਸ਼ਨ ਪਛਾਣਕਰਤਾ ਲੈ ਕੇ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਸੰਭਾਲਿਆ ਬ੍ਰਾਊਜ਼ਰ ਆਰਕਾਈਵ ਤੁਹਾਡੀ ਉਮੀਦ ਤੋਂ ਵੱਧ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਟਿਕਟ ਵਿੱਚ ਕੁਝ ਵੀ ਪੇਸਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਵੈਰੀ ਸਟ੍ਰਿੰਗ ਹਟਾਓ।

ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੇ URL ਬਾਰੇ ਧਾਰਨਾ

Magento ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਪੂਰਨ URL ਬਣਾਉਂਦਾ ਹੈ, ਹਰ ਵੈਬਸਾਈਟ ਜਾਂ ਸਟੋਰ ਵਿਊ ਅਨੁਸਾਰ ਸੀਮਿਤ। bin/magento config:show web/secure/base_url ਉਹ ਮੁੱਲ ਛਾਪਦਾ ਹੈ ਜਿਸ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਅਕਸਰ ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਵਰਤਿਆ ਨਾਮ ਨਹੀਂ, ਸਗੋਂ ਕਿਸੇ ਬਿਲਡ ਜਾਂ ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਚਿਆ ਹੋਸਟਨਾਮ ਹੁੰਦਾ ਹੈ। ਜੇ ਉੱਥੇ ਅੰਦਰੂਨੀ ਹੋਸਟ ਦਾ ਨਾਮ ਹੈ, ਤਾਂ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਅਜਿਹੀ ਥਾਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਜਾ ਨਹੀਂ ਸਕਦਾ, ਅਤੇ ਟਨਲ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।

ਸੁਰੱਖਿਅਤ ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਬੇਸ URL ਦੀ ਤੁਲਨਾ ਤੁਹਾਡੇ ਸਾਹਮਣੇ ਦੇ ਜਨਤਕ ਨਾਵਾਂ ਨਾਲ ਕਰੋ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਵਿੱਚ ਅਸੰਗਤੀ ਉਹੀ ਰੀਡਾਇਰੈਕਟ ਪੈਦਾ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਦੇਖ ਰਹੇ ਹੋ।

ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਕਸੀ ਹੈਡਰ ਇੱਕ ਸਮਝੌਤਾ ਹਨ

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

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

ਜਦੋਂ ਲੂਪ ਸੈਸ਼ਨ ਹੁੰਦਾ ਹੈ, ਰੂਟ ਨਹੀਂ

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

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