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

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋ ਸਵਾਲ ਵੱਖ ਕਰੋ: ਕਿਹੜੀ ਮਸ਼ੀਨ ਬੇਨਤੀ ਭੇਜਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਕਿਹੜਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

ਬੇਨਤੀ ਕਦੇ ਵੀ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ’ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦੀ

ਬ੍ਰਾਊਜ਼ਰ ਟੈਬ ਲੈਪਟਾਪ ਤੋਂ, VPN ਅਡੈਪਟਰ, ਅੰਦਰੂਨੀ DNS ਪਿਛੇਤਰ ਰਾਹੀਂ ਨਿੱਜੀ ਸਬਨੈੱਟ ਵਿੱਚ ਭੇਜਦੀ ਹੈ। UrlFetchApp Google ਵੱਲੋਂ ਸੰਭਾਲੇ ਹੋਸਟ ਤੋਂ ਭੇਜਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ Google ਦੇ ਰਿਜ਼ੌਲਵਰ, Google ਦੇ ਨਿਕਾਸ ਪਤੇ ਦੇਖਦਾ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਸਪਲਿਟ-ਟਨਲ ਮਾਰਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਨਹੀਂ ਦੇਖਦਾ। ਦੋਵੇਂ ਮਾਰਗ ਇੱਕ ਸਪ੍ਰੈਡਸ਼ੀਟ ਦਸਤਾਵੇਜ਼ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਨੈੱਟਵਰਕ ਟਿਕਾਣਾ ਨਹੀਂ। ਐਪ ਦੇ ਪਹੁੰਚ ਲਾਗ ਵਿੱਚ ਸਕ੍ਰਿਪਟ ਦੀ ਕੋਸ਼ਿਸ਼ VPN ਪੂਲ ਦੇ ਪਤੇ ਵਜੋਂ ਨਹੀਂ, ਸਗੋਂ Google ਪਤੇ ਵਜੋਂ ਦਿਖਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਸਭ ਤੋਂ ਤੇਜ਼ ਪੁਸ਼ਟੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮਿਲੇਗੀ।

ਇਸ ਲਈ ਸਥਾਨਕ ਸੁਧਾਰ ਕੁਝ ਨਹੀਂ ਕਰਦੇ। ਲੈਪਟਾਪ ਨੂੰ ਦੂਜੇ ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ, VPN ਕਲਾਇੰਟ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨਾ ਜਾਂ hosts ਵਿੱਚ ਐਂਟਰੀ ਜੋੜਨਾ ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਮਾਰਗ ਬਦਲਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰਿਪਟ ਦਾ ਮਾਰਗ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਛੱਡ ਦਿੰਦਾ ਹੈ।

ਇਹ ਕੀ ਬਾਹਰ ਕਰਦਾ ਹੈ

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

ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਲੈਪਟਾਪ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਕੂਕੀ ਜਾਂ SSO ਸੈਸ਼ਨ ਬੇਨਤੀ ਨਾਲ ਨਹੀਂ ਜਾਂਦਾ, ਕਿਉਂਕਿ ਬੇਨਤੀ ਸੈਸ਼ਨ ਸਥਿਤੀ ਤੋਂ ਬਿਨਾਂ ਨਵਾਂ HTTPS ਕਲਾਇੰਟ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ SSO ਰੀਡਾਇਰੈਕਟ ’ਤੇ ਨਿਰਭਰ ਕੋਈ ਵੀ ਚੀਜ਼ ਤੁਹਾਡੇ ਡੇਟਾ ’ਤੇ ਨਹੀਂ, ਉਸੇ ਰੀਡਾਇਰੈਕਟ ’ਤੇ ਖਤਮ ਹੁੰਦੀ ਹੈ।

ਦੋ ਵਿਹਾਰਕ ਰੂਪ

ਪਹਿਲਾ ਰੂਪ ਸਕ੍ਰਿਪਟ ਨੂੰ ਮਨਜ਼ੂਰ API ਦਿੰਦਾ ਹੈ। ਅੰਦਰੂਨੀ ਸੇਵਾ ਨੂੰ ਉਸ ਗੇਟਵੇ ਪਿੱਛੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਜੋ ਕਾਲ ਕਰਨ ਵਾਲੇ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚਦਾ ਹੈ, ਫਿਰ ਸਕ੍ਰਿਪਟ ਉਹ ਪ੍ਰਮਾਣ ਪੱਤਰ ਪੇਸ਼ ਕਰੇ ਜੋ ਗੇਟਵੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਸੇਵਾ ਖਾਤੇ ਦਾ ਟੋਕਨ। Apps Script ਵਿੱਚ ਇਸ ਦਾ ਅਰਥ OAuth2 ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ScriptApp.getOAuthToken() ਹੈ, ਨਾਲ ਹੀ API ਪਾਸੇ IP ਸੂਚੀ ਦੀ ਥਾਂ ਕਾਲ ਕਰਨ ਵਾਲੇ ਦੀ ਪਛਾਣ ਦੀ ਮਨਜ਼ੂਰ ਸੂਚੀ।

ਦੂਜਾ ਰੂਪ ਦਿਸ਼ਾ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਅੰਦਰੂਨੀ ਕੰਮ ਨਿੱਜੀ ਸਿਸਟਮ ਨੂੰ ਪੁੱਛਦਾ ਹੈ ਅਤੇ ਨਿਯੰਤਰਿਤ ਨਤੀਜਾ ਸਕ੍ਰਿਪਟ ਵੱਲੋਂ ਪੜ੍ਹੀ ਜਾਣ ਵਾਲੀ Sheet, Cloud Storage ਵਸਤੂ ਜਾਂ BigQuery ਸਾਰਣੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। Cloud Run ਕੰਮ, ਸਥਾਨਕ ਸ਼ਡਿਊਲਰ ਜਾਂ ਮੌਜੂਦਾ ETL ਕਦਮ ਉਹ ਕੰਮ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਆਉਂਦਾ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ। ਫਿਰ ਸਪ੍ਰੈਡਸ਼ੀਟ ਇੰਟਰਫੇਸ ਦੀ ਥਾਂ ਡੇਟਾਸੈਟ ਵਰਤਦੀ ਹੈ।

ਕਿਹੜਾ ਰੂਪ ਜਿੱਤੇਗਾ ਇਹ ਤਾਜ਼ਗੀ, ਖੇਤਰ-ਪੱਧਰੀ ਨਿਯੰਤਰਣ ਅਤੇ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਪਾਠਕ ਦਾ ਆਡਿਟ ਕੌਣ ਕਰ ਸਕਦਾ ਹੈ।

ਪ੍ਰਕਾਸ਼ਿਤ ਨਤੀਜੇ ਵਿੱਚ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

API ਦਿਸ਼ਾ ਲਈ ਵੀ ਸਮਝੌਤਾ ਚਾਹੀਦਾ ਹੈ: ਗੇਟਵੇ ਕਿਹੜਾ ਪ੍ਰਮਾਣ ਪੱਤਰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਟੋਕਨ ਕਿਹੜੇ scopes ਢੋਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਕਾਲ ਕਰਨ ਵਾਲੇ ਦੀਆਂ ਪਛਾਣਾਂ ਮਨਜ਼ੂਰ ਹਨ। ਸਾਈਨ-ਇਨ ਪੰਨਾ ਵਾਲਾ 200 ਜਵਾਬ ਸਫਲ ਕਾਲ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ ਸਥਿਤੀ ਕੋਡ ਨਹੀਂ, ਬਾਡੀ ਵੀ ਜਾਂਚੋ।

ਗਲਤੀ ਨੂੰ ਸਹੀ ਪਾਸੇ ਤੋਂ ਪੜ੍ਹੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ