ਦਫ਼ਤਰ ਅਤੇ VPN ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਇੱਕ CiviCRM URL: ਸੈੱਟਅੱਪ ਕਦਮ

ਦਫ਼ਤਰ ਦਾ ਲੈਪਟਾਪ ਆਪਣੀ ਮੇਜ਼ 'ਤੇ ਅਤੇ ਘਰੋਂ VPN ਰਾਹੀਂ ਦੁਬਾਰਾ ਉਹੀ CiviCRM ਬੁੱਕਮਾਰਕ ਖੋਲ੍ਹਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਰਤੋਂਕਾਰਾਂ ਨਾਲ ਸੰਪਰਕ ਝੱਲਣ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਇੱਕ ਕੈਨੋਨੀਕਲ ਪਤਾ ਹੈ, ਮੰਨ ਲਓ https://crm.example.org/, ਹਰ ਸਥਾਨ ਤੋਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਨੈੱਟਵਰਕ ਰਾਹ ਅਤੇ ਉਸ ਨਾਮ ਲਈ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਨਾਲ। VPN ਬਦਲਦਾ ਹੈ ਕਿ ਇੱਕ ਰਿਮੋਟ ਕਲਾਇੰਟ ਸਰਵਰ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ। ਇਸ ਨੂੰ ਕਦੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਛਾਣ ਨਹੀਂ ਬਦਲਣੀ ਚਾਹੀਦੀ, ਕਿਉਂਕਿ ਜਿਸ ਪਲ ਇਹ ਬਦਲਦਾ ਹੈ, ਹਰ ਬਣਾਇਆ ਗਿਆ ਲਿੰਕ, ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਕਾਲਬੈਕ ਹੱਲ ਕਰਨ ਵਾਲੀ ਦੂਜੀ ਸਮੱਸਿਆ ਬਣ ਜਾਂਦਾ ਹੈ।

ਰਸਤਾ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ URL ਚੁਣੋ

ਪਹਿਲਾਂ ਲੋੜੀਂਦਾ ਪਤਾ ਲਿਖੋ, CMS ਨੂੰ ਲੋੜੀਂਦੇ ਕਿਸੇ ਵੀ ਪਾਥ ਹਿੱਸੇ ਸਮੇਤ, ਅਤੇ ਇਸਨੂੰ ਸਥਿਰ ਬਿੰਦੂ ਮੰਨੋ। ਇਸ ਰਨਬੁੱਕ ਵਿੱਚ ਬਾਕੀ ਸਭ ਕੁਝ ਲਾਗੂ ਕਰਨ ਦਾ ਵੇਰਵਾ ਹੈ ਜੋ ਇਸਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ: ਕਿਹੜਾ DNS ਜਵਾਬ ਹਰ ਗਰੁੱਪ ਨੂੰ ਮਿਲਦਾ ਹੈ, ਕਿਹੜਾ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਿਸਨਰ ਨੂੰ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੀ ਟ੍ਰੈਫਿਕ ਟਨਲ ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ ਜਾਂ ਸਥਾਨਕ ਸਵਿੱਚ ਪੋਰਟ ਰਾਹੀਂ।

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

ਕਦਮ 1: ਦੋਵੇਂ ਗਰੁੱਪਾਂ ਲਈ ਨਾਮ ਸਹੀ ਢੰਗ ਨਾਲ ਰਿਜ਼ੋਲਵ ਹੋਵੇ

ਦੋਵੇਂ ਗਰੁੱਪਾਂ ਨੂੰ ਨਿੱਜੀ ਜਵਾਬ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਤੱਕ ਉਹ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚ ਸਕਣ, ਅਤੇ ਇਹ ਜਾਇਜ਼ ਹੈ ਕਿ ਜਵਾਬ ਵੱਖਰੇ ਹੋਣ ਜਿੰਨਾ ਚਿਰ ਨਾਮ ਵੱਖਰਾ ਨਹੀਂ। LAN ਕਲਾਇੰਟ ਅੰਦਰੂਨੀ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਰਿਜ਼ੋਲਵ ਕਰਦੇ ਹਨ; VPN ਕਲਾਇੰਟਾਂ ਨੂੰ ਅਜਿਹੀ ਰਿਜ਼ੋਲਵਰ ਨੀਤੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਉਹੀ ਜ਼ੋਨ ਦੇਵੇ, ਨਾ ਕਿ ਕਿਊਰੀ ਨੂੰ ਜਨਤਕ ਰਿਜ਼ੋਲਵਰ ਵੱਲ ਲੀਕ ਕਰੇ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਜਨਤਕ ਜਵਾਬ ਦੇਵੇ ਜੋ ਉਹ ਵਰਤ ਨਹੀਂ ਸਕਦੇ।

ਅਨੁਮਾਨ ਲਾਉਣ ਦੀ ਬਜਾਏ ਹਰ ਸੰਦਰਭ ਤੋਂ ਨਾਮ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ curl ਦੇ resolve ਵਿਕਲਪ ਨਾਲ DNS ਤੋਂ ਸੁਤੰਤਰ ਰਾਹ ਦੀ ਜਾਂਚ ਕਰੋ, ਜੋ ਇੱਕ ਬੇਨਤੀ ਲਈ ਪਤਾ ਪਿੰਨ ਕਰਦਾ ਹੈ:

dig +short crm.example.org
curl -sSI --resolve crm.example.org:443:10.10.5.20 https://crm.example.org/ | head -5

ਜੇ ਪਹਿਲੀ ਜਾਂਚ ਅਜਿਹਾ ਪਤਾ ਦਿੰਦੀ ਹੈ ਜਿਸ ਤੱਕ ਕਲਾਇੰਟ ਪਹੁੰਚ ਨਹੀਂ ਸਕਦਾ, ਤਾਂ ਟਨਲ ਰੂਟਿੰਗ ਜਾਂ ਸਪਲਿਟ-ਟਨਲ ਸੂਚੀ ਸਮੱਸਿਆ ਹੈ। ਜੇ ਦੂਜੀ ਜਾਂਚ ਤੁਹਾਡੇ ਅਨੁਮਾਨ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਹੋਸਟਨਾਮ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਰੁਕੋ ਅਤੇ Location ਹੈਡਰ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਕੋਈ ਰਸਤਾ ਬਦਲਾਅ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰੇਗਾ।

ਕਦਮ 2: ਵੈੱਬ ਸਰਵਰ, ਸਰਟੀਫਿਕੇਟ ਅਤੇ CMS ਬੇਸ URL ਨੂੰ ਮਿਲਾਓ

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

ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਪਿੱਛੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪਤਾ ਹੈ ਕਿ ਬੇਨਤੀ HTTPS ਰਾਹੀਂ ਆਈ ਸੀ। ਜ਼ਿਆਦਾਤਰ CMS ਪਲੇਟਫਾਰਮ ਖੋਜੇ ਗਏ ਸਕੀਮ ਤੋਂ ਪੂਰਨ ਲਿੰਕ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਮੂਲ ਸਕੀਮ ਅੱਗੇ ਭੇਜੇ ਬਿਨਾਂ TLS ਖਤਮ ਕਰਨ ਵਾਲੀ ਪ੍ਰੌਕਸੀ http:// ਸਰੋਤਾਂ ਨਾਲ ਭਰਿਆ ਪੰਨਾ ਬਣਾਉਂਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਰੋਕ ਸਕਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਅਨੁਮਾਨ ਲਾਉਣ ਦੇਣ ਦੀ ਬਜਾਏ ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਕਸੀ ਅਤੇ ਅੱਗੇ ਭੇਜੇ ਹੈਡਰ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਕਰੋ।

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

cv flush
# then Administer > System Settings > Cleanup Caches and Update Paths

ਕਦਮ 3: CiviCRM ਵੱਲੋਂ ਬਣਾਏ ਪਤਿਆਂ ਦੀ ਜਾਂਚ ਕਰੋ

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

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

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

ਬੇਨਤੀ ਦਾ ਹੋਸਟਨਾਮ ਭਰੋਸੇ ਦਾ ਫ਼ੈਸਲਾ ਨਹੀਂ ਹੈ

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

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

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