ਆਪਣੀ ਐਪ ਵਿੱਚ ਲੌਗਇਨ ਕਿਵੇਂ ਜੋੜੀਏ: ਪਾਸਵਰਡ, ਮੈਜਿਕ ਲਿੰਕ, Google ਅਤੇ ਭੂਮਿਕਾਵਾਂ

ਆਪਣੀ ਐਪ ਵਿੱਚ ਲੌਗਇਨ ਜੋੜਨ ਲਈ, ਇੱਕ ਤਰੀਕਾ ਚੁਣੋ: ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ, ਮੈਜਿਕ ਲਿੰਕ (ਈਮੇਲ ਰਾਹੀਂ ਭੇਜਿਆ ਇੱਕ ਵਾਰ ਵਾਲਾ ਸਾਈਨ-ਇਨ ਲਿੰਕ), ਜਾਂ "Google ਨਾਲ ਸਾਈਨ ਇਨ ਕਰੋ"। ਇਸਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਲਿਖਣ ਦੀ ਬਜਾਏ ਕਿਸੇ ਭਰੋਸੇਮੰਦ ਆਥ ਲਾਇਬ੍ਰੇਰੀ ਜਾਂ ਹੋਸਟਡ ਪ੍ਰਦਾਤਾ ਰਾਹੀਂ ਲਾਗੂ ਕਰੋ। ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਹਰ ਕਿਸਮ ਦਾ ਯੂਜ਼ਰ ਕੀ ਕਰ ਸਕਦਾ ਹੈ (ਭੂਮਿਕਾਵਾਂ), ਅਤੇ ਇਹ ਹਰ ਪੇਜ ਅਤੇ API ਬੇਨਤੀ 'ਤੇ ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਕਰੋ। ਸੈਸ਼ਨ ਸੁਰੱਖਿਅਤ ਕੁਕੀਜ਼ ਵਰਤਣ, ਖਤਮ ਹੋਣ, ਅਤੇ ਲੌਗਆਉਟ 'ਤੇ ਠੀਕ ਤਰ੍ਹਾਂ ਬੰਦ ਹੋਣ।

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

ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ: ਕੀ ਤੁਹਾਨੂੰ ਲੌਗਇਨ ਚਾਹੀਦਾ ਹੈ?

ਲੌਗਇਨ ਰੁਕਾਵਟ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਦੋਵੇਂ ਜੋੜਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਇਸਦੀ ਲੋੜ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ:

• ਯੂਜ਼ਰਾਂ ਕੋਲ ਨਿੱਜੀ ਡੇਟਾ ਹੋਵੇ (ਉਨ੍ਹਾਂ ਦੀਆਂ ਬੁਕਿੰਗਾਂ, ਦਸਤਾਵੇਜ਼, ਇਨਵਾਇਸ)
• ਯੂਜ਼ਰ ਉਹ ਚੀਜ਼ਾਂ ਬਦਲ ਸਕਣ ਜੋ ਦੂਜੇ ਵੇਖਣਗੇ
• ਤੁਸੀਂ ਪਹੁੰਚ ਲਈ ਪੈਸੇ ਲੈਂਦੇ ਹੋ
• ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਇਜਾਜ਼ਤਾਂ ਚਾਹੀਦੀਆਂ ਹੋਣ (ਮਾਲਕ, ਸਟਾਫ, ਗਾਹਕ)

ਤੁਹਾਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੋ ਸਕਦੀ ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟ, ਇੱਕ ਜਨਤਕ ਡਾਇਰੈਕਟਰੀ, ਜਾਂ ਇੱਕ ਫਾਰਮ ਲਈ ਜੋ ਸਿਰਫ਼ ਤੁਹਾਨੂੰ ਈਮੇਲ ਭੇਜਦਾ ਹੈ। ਵੇਟਲਿਸਟ ਨੂੰ ਅਕਾਊਂਟ ਦੀ ਲੋੜ ਨਹੀਂ; ਇੱਕ ਈਮੇਲ ਖੇਤਰ ਕਾਫ਼ੀ ਹੈ।

ਚਾਰ ਆਮ ਲੌਗਇਨ ਤਰੀਕੇ

ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਦੋ ਜੋੜਦੀਆਂ ਹਨ: Google ਸਾਈਨ-ਇਨ ਅਤੇ ਈਮੇਲ ਮੈਜਿਕ ਲਿੰਕ ਇੱਕ ਮਸ਼ਹੂਰ ਜੋੜੀ ਹੈ ਜੋ ਬਿਨਾਂ ਕੋਈ ਪਾਸਵਰਡ ਸੰਭਾਲੇ ਜ਼ਿਆਦਾਤਰ ਲੋਕਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।

ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ

ਜੇ ਤੁਸੀਂ ਪਾਸਵਰਡ ਦੇ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਲਾਜ਼ਮੀ ਹਨ:

• ਪਾਸਵਰਡ ਨੂੰ ਹੌਲੀ ਪਾਸਵਰਡ-ਹੈਸ਼ਿੰਗ ਐਲਗੋਰਿਦਮ ਨਾਲ ਹੈਸ਼ ਕਰੋ। OWASP ਦੀ ਪਾਸਵਰਡ ਸਟੋਰੇਜ ਮਾਰਗਦਰਸ਼ਨ Argon2id ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੀ ਹੈ, ਅਤੇ scrypt, bcrypt ਜਾਂ PBKDF2 ਬਦਲ ਵਜੋਂ। ਪਾਸਵਰਡ ਕਦੇ ਸਾਦੇ ਟੈਕਸਟ ਵਿੱਚ ਜਾਂ ਤੇਜ਼ ਆਮ ਹੈਸ਼ ਨਾਲ ਨਾ ਰੱਖੋ।
• ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਇੱਕ ਬੇਤਰਤੀਬ, ਇੱਕ ਵਾਰ ਵਰਤੋਂ ਵਾਲਾ, ਖਤਮ ਹੋਣ ਵਾਲਾ ਲਿੰਕ ਵਰਤਣ, ਜੋ ਤਸਦੀਕ ਕੀਤੀ ਈਮੇਲ 'ਤੇ ਭੇਜਿਆ ਜਾਵੇ।
• ਇਹ ਨਾ ਦੱਸੋ ਕਿ ਕਿਹੜੀਆਂ ਈਮੇਲਾਂ ਦੇ ਅਕਾਊਂਟ ਹਨ। "ਜੇ ਇਹ ਈਮੇਲ ਰਜਿਸਟਰ ਹੈ, ਤਾਂ ਅਸੀਂ ਰੀਸੈੱਟ ਲਿੰਕ ਭੇਜ ਦਿੱਤਾ ਹੈ" ਕਹਿਣਾ "ਕੋਈ ਅਕਾਊਂਟ ਨਹੀਂ ਮਿਲਿਆ" ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ।
• ਲੌਗਇਨ ਅਤੇ ਰੀਸੈੱਟ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਰੇਟ ਸੀਮਿਤ ਕਰੋ ਤਾਂ ਕਿ ਪਾਸਵਰਡ ਦਾ ਅਨੁਮਾਨ ਹੌਲੀ ਹੋਵੇ।
• ਲੰਮੇ ਪਾਸਵਰਡਾਂ ਅਤੇ ਪਾਸਵਰਡ ਮੈਨੇਜਰਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ; ਅਜੀਬ ਅੱਖਰ ਮਿਸ਼ਰਣ ਦੇ ਨਿਯਮ ਛੱਡ ਦਿਓ।

ਮੈਜਿਕ ਲਿੰਕ ਅਤੇ ਇੱਕ ਵਾਰ ਵਾਲੇ ਕੋਡ

ਮੈਜਿਕ ਲਿੰਕ ਯੂਜ਼ਰ ਨੂੰ ਈਮੇਲ ਕੀਤਾ ਸਾਈਨ-ਇਨ ਲਿੰਕ ਹੈ। ਉਸ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਨਾਲ ਯੂਜ਼ਰ ਲੌਗਇਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਵਾਲਾ ਕੋਡ ਉਹੀ ਵਿਚਾਰ ਹੈ, ਪਰ ਕਲਿੱਕ ਦੀ ਥਾਂ ਟਾਈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

• ਲਿੰਕ ਅਤੇ ਕੋਡ ਜਲਦੀ ਖਤਮ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਵਾਰ ਚੱਲਦੇ ਹਨ।
• ਲਿੰਕ ਨੂੰ ਉਸੇ ਡਿਵਾਈਸ 'ਤੇ ਲੌਗਇਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਯੂਜ਼ਰ ਨੇ ਕਲਿੱਕ ਕੀਤਾ, ਅਤੇ ਟੋਕਨ ਲੌਗਾਂ ਜਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲਾਂ ਵਿੱਚ ਨਹੀਂ ਰਹਿਣਾ ਚਾਹੀਦਾ।
• ਤੁਹਾਨੂੰ ਭਰੋਸੇਯੋਗ ਈਮੇਲ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ — ਦੇਖੋ ਆਪਣੀ ਐਪ ਤੋਂ ਈਮੇਲ ਕਿਵੇਂ ਭੇਜੀਏ। Gmail ਅਤੇ Outlook 'ਤੇ ਜਾਂਚੋ, ਅਤੇ ਸਪੈਮ ਫੋਲਡਰ ਵੀ ਦੇਖੋ।

Google ਨਾਲ ਸਾਈਨ-ਇਨ (ਅਤੇ ਹੋਰ OAuth ਪ੍ਰਦਾਤਾ)

"Google ਨਾਲ ਸਾਈਨ ਇਨ ਕਰੋ" OAuth ਅਤੇ OpenID Connect ਵਰਤਦਾ ਹੈ: Google ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਕੌਣ ਹੈ ਅਤੇ ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਉਨ੍ਹਾਂ ਦੀ ਈਮੇਲ ਅਤੇ ਨਾਮ ਦੱਸਦਾ ਹੈ। ਸਤੰਬਰ 2026 ਤੱਕ ਸੈੱਟਅੱਪ Google Cloud Console ਦੇ Google Auth Platform ਭਾਗ ਵਿੱਚ ਹੁੰਦਾ ਹੈ:

1. ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਬਣਾਓ ਜਾਂ ਚੁਣੋ, ਅਤੇ Branding ਪੇਜ ਭਰੋ, ਯਾਨੀ ਕਿ ਯੂਜ਼ਰ ਸਹਿਮਤੀ ਸਕਰੀਨ 'ਤੇ ਕੀ ਵੇਖਦੇ ਹਨ (ਐਪ ਦਾ ਨਾਮ, ਸਹਾਇਤਾ ਈਮੇਲ, ਲੋਗੋ)।
2. Clients ਪੇਜ 'ਤੇ "Web application" ਕਿਸਮ ਦਾ client ਬਣਾਓ।
3. ਆਪਣੇ authorized JavaScript origins ਅਤੇ redirect URIs ਜੋੜੋ: ਉਹ ਸਹੀ ਪਤੇ ਜਿੱਥੇ ਤੁਹਾਡੀ ਐਪ ਚੱਲਦੀ ਹੈ ਅਤੇ ਜਿੱਥੇ Google ਸਾਈਨ-ਇਨ ਤੋਂ ਬਾਅਦ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।
4. Client ID ਅਤੇ client secret ਆਪਣੀ ਐਪ ਦੇ ਸੀਕ੍ਰੇਟਾਂ ਵਿੱਚ ਰੱਖੋ।

Google ਦੇ OAuth ਦਸਤਾਵੇਜ਼ਾਂ ਅਨੁਸਾਰ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਹੁੰਦਾ ਹੈ:

• redirect_uri_mismatch: redirect ਪਤਾ ਬਿਲਕੁਲ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ http ਬਨਾਮ https, ਵੱਡੇ-ਛੋਟੇ ਅੱਖਰ ਅਤੇ ਅੰਤ ਵਿੱਚ ਸਲੈਸ਼ ਸ਼ਾਮਲ ਹਨ। ਆਪਣੇ ਪ੍ਰੀਵਿਊ ਪਤੇ ਅਤੇ ਲਾਈਵ ਡੋਮੇਨ ਦੋਵਾਂ ਲਈ ਇੱਕ-ਇੱਕ ਜੋੜੋ।
• HTTPS ਲਾਜ਼ਮੀ: redirect URIs ਨੂੰ HTTPS ਵਰਤਣਾ ਪੈਂਦਾ ਹੈ, ਵਿਕਾਸ ਦੌਰਾਨ localhost ਤੋਂ ਬਿਨਾਂ।
• state ਪੈਰਾਮੀਟਰ ਵਾਪਸ ਆਉਣ 'ਤੇ ਜਾਂਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਕਿ cross-site request forgery ਤੋਂ ਬਚਾਅ ਹੋਵੇ। ਚੰਗੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਇਹ ਤੁਹਾਡੇ ਲਈ ਕਰਦੀਆਂ ਹਨ।

ਜੇ ਤੁਸੀਂ ਸਿਰਫ਼ ਬੁਨਿਆਦੀ ਸਾਈਨ-ਇਨ ਜਾਣਕਾਰੀ (ਨਾਮ, ਈਮੇਲ, ਪ੍ਰੋਫਾਈਲ) ਮੰਗਦੇ ਹੋ, ਤਾਂ Google ਕਹਿੰਦਾ ਹੈ ਕਿ ਐਪ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਾਜ਼ਮੀ ਨਹੀਂ। ਯੂਜ਼ਰਾਂ ਦੀ Gmail, Drive ਜਾਂ Calendar ਦੀ ਪਹੁੰਚ ਮੰਗਣਾ ਵੱਖਰੀ ਗੱਲ ਹੈ ਅਤੇ ਇਸਦੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲੱਗਦੀ ਹੈ।

ਖੁਦ ਬਣਾਉਣਾ ਜਾਂ ਪ੍ਰਦਾਤਾ ਵਰਤਣਾ?

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

ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਇਜਾਜ਼ਤਾਂ

ਲੌਗਇਨ ਦੱਸਦਾ ਹੈ ਕਿ ਕੌਣ ਹੈ। ਇਜਾਜ਼ਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ। ਸ਼ੁਰੂ ਵਿੱਚ ਸਧਾਰਨ ਰੱਖੋ:

ਭੂਮਿਕਾਵਾਂ ਦੇ ਨਾਮਾਂ ਨਾਲੋਂ ਇਹ ਨਿਯਮ ਜ਼ਿਆਦਾ ਅਹਿਮ ਹਨ:

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

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

ਸੈਸ਼ਨ ਸੁਰੱਖਿਆ

ਲੌਗਇਨ ਤੋਂ ਬਾਅਦ, ਐਪ ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਸੈਸ਼ਨ ਰਾਹੀਂ ਯਾਦ ਰੱਖਦੀ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕੁਕੀ। OWASP ਦੀ ਸੈਸ਼ਨ ਪ੍ਰਬੰਧਨ ਮਾਰਗਦਰਸ਼ਨ ਇਹ ਸਿਫ਼ਾਰਸ਼ ਕਰਦੀ ਹੈ:

• ਸੈਸ਼ਨ ਕੁਕੀਜ਼ Secure (ਸਿਰਫ਼ HTTPS), HttpOnly (ਪੇਜ ਸਕ੍ਰਿਪਟਾਂ ਲਈ ਅਪਹੁੰਚ) ਅਤੇ SameSite ਨਾਲ ਸੈੱਟ ਹੋਣ
• ਲੌਗਇਨ 'ਤੇ ਨਵਾਂ ਸੈਸ਼ਨ ID ਜਾਰੀ ਹੋਵੇ, ਅਤੇ ਜਦੋਂ ਇਜਾਜ਼ਤਾਂ ਬਦਲਣ ਤਾਂ ਫਿਰ
• ਸਰਵਰ 'ਤੇ ਲਾਗੂ ਇੱਕ ਵਿਹਲ ਟਾਈਮਆਊਟ ਅਤੇ ਇੱਕ ਅਧਿਕਤਮ ਉਮਰ ਸੀਮਾ
• ਲੌਗਆਉਟ ਜੋ ਸੈਸ਼ਨ ਨੂੰ ਸਰਵਰ 'ਤੇ ਖਤਮ ਕਰੇ, ਸਿਰਫ਼ ਕੁਕੀ ਮਿਟਾ ਕੇ ਨਹੀਂ
• ਯੂਜ਼ਰ ਦੇ ਪਾਸਵਰਡ ਬਦਲਣ 'ਤੇ ਸੈਸ਼ਨ ਰੱਦ ਹੋਣ

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

ਇੱਕ ਪ੍ਰੋਂਪਟ ਜੋ ਜ਼ਰੂਰੀ ਗੱਲਾਂ ਕਵਰ ਕਰਦਾ ਹੈ

ਇਸ ਐਪ ਵਿੱਚ ਯੂਜ਼ਰ ਅਕਾਊਂਟ ਜੋੜੋ। ਯੂਜ਼ਰ ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ ਨਾਲ ਸਾਈਨ ਅੱਪ ਅਤੇ ਲੌਗਇਨ ਕਰ ਸਕਣ, ਜਾਂ Google ਨਾਲ। ਕਸਟਮ ਆਥ ਕੋਡ ਦੀ ਥਾਂ [library or provider] ਵਰਤੋ। ਪਾਸਵਰਡ Argon2id ਜਾਂ bcrypt ਨਾਲ ਹੈਸ਼ ਕਰੋ। ਈਮੇਲ ਰਾਹੀਂ ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਜੋੜੋ, ਇੱਕ ਵਾਰ ਵਾਲਾ ਲਿੰਕ ਜੋ ਇੱਕ ਘੰਟੇ ਵਿੱਚ ਖਤਮ ਹੋਵੇ। ਸੈਸ਼ਨ ਸੁਰੱਖਿਅਤ, HttpOnly ਕੁਕੀਜ਼ ਵਿੱਚ ਰੱਖੋ। /dashboard ਅਤੇ ਹਰ /api ਰੂਟ ਦੀ ਰਾਖੀ ਕਰੋ ਤਾਂ ਕਿ ਸਿਰਫ਼ ਲੌਗਇਨ ਯੂਜ਼ਰ ਵਰਤ ਸਕਣ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਯੂਜ਼ਰ ਸਿਰਫ਼ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਵੇਖ ਸਕਣ। "admin" ਭੂਮਿਕਾ ਜੋੜੋ ਜੋ ਸਾਰੇ ਯੂਜ਼ਰ ਵੇਖ ਸਕੇ; ਸਿਰਫ਼ ਐਡਮਿਨ /admin ਤੱਕ ਪਹੁੰਚ ਸਕਣ, ਜੋ ਸਰਵਰ 'ਤੇ ਜਾਂਚਿਆ ਜਾਵੇ।

ਫਿਰ ਜਾਂਚੋ: ਸਾਈਨ ਅੱਪ ਕਰੋ, ਲੌਗਆਉਟ ਕਰੋ, ਲੌਗਇਨ ਕਰੋ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਕਰੋ, ਲੌਗਆਉਟ ਹਾਲਤ ਵਿੱਚ ਕੋਈ ਨਿੱਜੀ URL ਅਜ਼ਮਾਓ, ਅਤੇ ਦੂਜੇ ਯੂਜ਼ਰ ਦਾ ਰਿਕਾਰਡ ਅਜ਼ਮਾਓ।

AI ਨਾਲ ਬਣੇ ਲੌਗਇਨ ਵਿੱਚ ਆਮ ਗਲਤੀਆਂ

• ਸੁਰੱਖਿਆ ਸਿਰਫ਼ ਪੇਜ ਵਿੱਚ। ਪੇਜ ਲੌਗਆਉਟ ਯੂਜ਼ਰਾਂ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਦਾ ਹੈ, ਪਰ API ਕਿਸੇ ਨੂੰ ਵੀ ਡੇਟਾ ਵਾਪਸ ਦਿੰਦਾ ਹੈ।
• ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਸੀਕ੍ਰੇਟ। OAuth client secrets ਅਤੇ ਆਥ ਪ੍ਰਦਾਤਾ ਦੀਆਂ ਐਡਮਿਨ ਕੀਆਂ ਸਰਵਰ 'ਤੇ ਰਹਿਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।
• ਪ੍ਰੀਵਿਊ ਅਤੇ ਲਾਈਵ URL ਰਲ ਜਾਣਾ। Google ਦਾ redirect URI ਜਾਂ ਰੀਸੈੱਟ ਈਮੇਲ ਦਾ ਲਿੰਕ ਪ੍ਰੀਵਿਊ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਲੌਗਇਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ।
• ਈਮੇਲ ਤਸਦੀਕ ਨਾ ਹੋਣਾ। ਕੋਈ ਵੀ anyone@company.com ਵਜੋਂ ਸਾਈਨ ਅੱਪ ਕਰ ਸਕਦਾ ਹੈ। ਉਸ ਈਮੇਲ ਨਾਲ ਜੁੜੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਈਮੇਲ ਤਸਦੀਕ ਕਰੋ।
• ਸਿਰਫ਼ ਸਹੀ ਰਾਹ (happy path) ਦੀ ਜਾਂਚ। ਗਲਤ ਪਾਸਵਰਡ, ਖਤਮ ਹੋਏ ਲਿੰਕ ਅਤੇ ਦੂਜੇ ਅਕਾਊਂਟ ਨਾਲ ਵੀ ਅਜ਼ਮਾਓ।

Mythex ਵਿੱਚ ਲੌਗਇਨ ਜੋੜਨਾ

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

1. ਇੱਕ ਤਰੀਕਾ ਚੁਣੋ, ਜਿਵੇਂ ਤੁਹਾਡੇ ਆਪਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਈਮੇਲ ਅਤੇ ਪਾਸਵਰਡ, ਜਾਂ ਕਿਸੇ ਹੋਸਟਡ ਪ੍ਰਦਾਤਾ ਦਾ SDK।
2. ਜੇ ਤੁਸੀਂ ਯੂਜ਼ਰ ਖੁਦ ਸੰਭਾਲਦੇ ਹੋ, ਤਾਂ ਐਪ ਨੂੰ ਡੇਟਾਬੇਸ ਚਾਹੀਦਾ ਹੈ; ਚੈਟ ਵਿੱਚ ਮੰਗੋ ਜਾਂ /database ਵਰਤੋ।
3. ਪ੍ਰਦਾਤਾ ਦੀਆਂ ਕੀਆਂ ਪ੍ਰੋਜੈਕਟ ਸੀਕ੍ਰੇਟਾਂ ਵਿੱਚ ਰੱਖੋ (/secrets ਜਾਂ ਪ੍ਰੋਜੈਕਟ ਸੈਟਿੰਗਾਂ)।
4. ਉੱਪਰ ਵਰਗਾ ਪ੍ਰੋਂਪਟ ਵਰਤੋ, ਫਿਰ Preview ਵਿੱਚ ਜਾਂਚੋ। Google ਸਾਈਨ-ਇਨ ਲਈ, ਆਪਣੇ ਪ੍ਰੀਵਿਊ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਪਤੇ ਦੋਵਾਂ ਲਈ redirect URIs ਜੋੜੋ।

ਦੇਖੋ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ Add login to your app। ਜੇ ਤੁਸੀਂ ਕੋਈ ਅਦਾਇਗੀ ਉਤਪਾਦ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ SaaS MVP ਕਿਵੇਂ ਬਣਾਈਏ ਅਕਾਊਂਟ ਅਤੇ ਬਿਲਿੰਗ ਇਕੱਠੇ ਕਵਰ ਕਰਦਾ ਹੈ।

ਸਵਾਲ