ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗಿನ್ ಸೇರಿಸುವುದು ಹೇಗೆ: ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್‌ಗಳು, Google ಮತ್ತು ಪಾತ್ರಗಳು
ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗಿನ್ ಸೇರಿಸಲು, ಒಂದು ವಿಧಾನ ಆರಿಸಿ — ಇಮೇಲ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್, ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್‌ಗಳು (ಇಮೇಲ್ ಮೂಲಕ ಕಳುಹಿಸಲಾದ ಒಂದು ಬಾರಿ ಸೈನ್-ಇನ್ ಲಿಂಕ್), ಅಥವಾ "Sign in with Google" — ಮತ್ತು ಅದನ್ನು ಸಾಬೀತಾದ ಆಥ್ ಲೈಬ್ರರಿ ಅಥವಾ ಹೋಸ್ಟ್ ಮಾಡಿದ ಪ್ರೊವೈಡರ್ ಮೂಲಕ ಅನುಷ್ಠಾನಗೊಳಿಸಿ, ಸ್ವಂತವಾಗಿ ಬರೆಯದೆ. ನಂತರ ಪ್ರತಿ ಬಳಕೆದಾರ ಪ್ರಕಾರ ಏನು ಮಾಡಬಹುದು ಎಂದು ನಿರ್ಧರಿಸಿ (ಪಾತ್ರಗಳು), ಮತ್ತು ಪ್ರತಿ ಪುಟ ಮತ್ತು API ವಿನಂತಿಗೆ ಸರ್ವರ್‌ನಲ್ಲಿ ಅದನ್ನು ಜಾರಿಗೊಳಿಸಿ. ಸೆಷನ್‌ಗಳು ಸುರಕ್ಷಿತ ಕುಕಿಗಳನ್ನು ಬಳಸಬೇಕು, ಅವಧಿ ಮುಗಿಯಬೇಕು, ಮತ್ತು ಲಾಗ್ಔಟ್‌ನಲ್ಲಿ ಸರಿಯಾಗಿ ಅಂತ್ಯಗೊಳ್ಳಬೇಕು.
ಈ ಮಾರ್ಗದರ್ಶಿ ಪ್ರತಿ ಆಯ್ಕೆಯನ್ನೂ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಲಾಗಿನ್ ಅನ್ನು ಸುರಕ್ಷಿತ ಲಾಗಿನ್‌ನಿಂದ ಬೇರ್ಪಡಿಸುವ ವಿವರಗಳನ್ನು ಹಂತ ಹಂತವಾಗಿ ತೋರಿಸುತ್ತದೆ. ಇದರ ಹಿಂದಿನ ಪರಿಕಲ್ಪನೆಗಳಿಗೆ, ದೃಢೀಕರಣ ಎಂದರೇನು ನೋಡಿ.
ಮೊದಲು ನಿರ್ಧರಿಸಿ: ನಿಮಗೆ ಲಾಗಿನ್ ಬೇಕೇ?
ಲಾಗಿನ್ ಅಡೆತಡೆ ಮತ್ತು ಜವಾಬ್ದಾರಿ ಸೇರಿಸುತ್ತದೆ. ಇದು ಬೇಕಾದಾಗ:
- ಬಳಕೆದಾರರಿಗೆ ಖಾಸಗಿ ಡೇಟಾ ಇದೆ (ಅವರ ಬುಕಿಂಗ್‌ಗಳು, ದಾಖಲೆಗಳು, ಇನ್‌ವಾಯ್ಸ್‌ಗಳು)
- ಬಳಕೆದಾರರು ಇತರರು ನೋಡುವ ವಸ್ತುಗಳನ್ನು ಬದಲಿಸಬಹುದು
- ನೀವು ಪ್ರವೇಶಕ್ಕೆ ಶುಲ್ಕ ವಿಧಿಸುತ್ತೀರಿ
- ಬೇರೆ ಬೇರೆ ಜನರಿಗೆ ಬೇರೆ ಅನುಮತಿಗಳು ಬೇಕು (ಮಾಲೀಕ, ಸಿಬ್ಬಂದಿ, ಗ್ರಾಹಕ)
ಮಾರ್ಕೆಟಿಂಗ್ ಸೈಟ್, ಸಾರ್ವಜನಿಕ ಡೈರೆಕ್ಟರಿ, ಅಥವಾ ಕೇವಲ ನಿಮಗೆ ಇಮೇಲ್ ಕಳುಹಿಸುವ ಫಾರ್ಮ್‌ಗೆ ನಿಮಗೆ ಇದು ಬೇಕಾಗಿಲ್ಲ. ವೇಟ್‌ಲಿಸ್ಟ್‌ಗೆ ಖಾತೆಗಳು ಬೇಡ; ಇಮೇಲ್ ಕ್ಷೇತ್ರ ಸಾಕು.
ಸಾಮಾನ್ಯ ನಾಲ್ಕು ಲಾಗಿನ್ ವಿಧಾನಗಳು
| ವಿಧಾನ | ಅದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ | ಅನುಕೂಲಗಳು | ಅನಾನುಕೂಲಗಳು |
|---|---|---|---|
| ಇಮೇಲ್ + ಪಾಸ್‌ವರ್ಡ್ | ಬಳಕೆದಾರ ಪಾಸ್‌ವರ್ಡ್ ರಚಿಸುತ್ತಾನೆ; ನೀವು ಅದರ ಹ್ಯಾಶ್ ಸಂಗ್ರಹಿಸುತ್ತೀರಿ | ಪರಿಚಿತ, ಇಮೇಲ್ ಇಲ್ಲದೆ ಆಫ್‌ಲೈನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ | ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆ, ಮರುಬಳಕೆ, ಉಲ್ಲಂಘನೆಗಳು; ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಗ್ರಹಿಸಬೇಕು |
| ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್ | ಬಳಕೆದಾರ ಇಮೇಲ್ ನಮೂದಿಸುತ್ತಾನೆ, ನೀವು ಕಳುಹಿಸಿದ ಲಿಂಕ್ ಕ್ಲಿಕ್ ಮಾಡುತ್ತಾನೆ | ಸಂಗ್ರಹಿಸಲು ಅಥವಾ ಮರೆಯಲು ಪಾಸ್‌ವರ್ಡ್‌ಗಳಿಲ್ಲ | ಇಮೇಲ್ ವಿತರಣೆಯ ಮೇಲೆ ಅವಲಂಬನೆ; ಲಾಗಿನ್ ನಿಧಾನ |
| ಒಂದು ಬಾರಿ ಕೋಡ್ | ಬಳಕೆದಾರ ಇಮೇಲ್ ನಮೂದಿಸುತ್ತಾನೆ, 6-ಅಂಕಿ ಕೋಡ್ ಟೈಪ್ ಮಾಡುತ್ತಾನೆ | ಲಿಂಕ್‌ಗಳು ತಪ್ಪು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ತೆರೆದರೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ | ಅದೇ ಇಮೇಲ್ ಅವಲಂಬನೆ |
| ಸಾಮಾಜಿಕ / OAuth (Google, Apple, GitHub, Microsoft) | ಇನ್ನೊಂದು ಪ್ರೊವೈಡರ್ ಬಳಕೆದಾರ ಯಾರೆಂದು ದೃಢೀಕರಿಸುತ್ತದೆ | ಬಳಕೆದಾರರಿಗೆ ಅತ್ಯಂತ ವೇಗ; ನೀವು ಸಂಗ್ರಹಿಸಲು ಪಾಸ್‌ವರ್ಡ್ ಇಲ್ಲ | ಬಳಕೆದಾರರಿಗೆ ಆ ಖಾತೆ ಬೇಕು; ಪ್ರೊವೈಡರ್‌ನಲ್ಲಿ ಸೆಟಪ್ |
ಅನೇಕ ಆ್ಯಪ್‌ಗಳು ಎರಡನ್ನು ಸೇರಿಸುತ್ತವೆ: Google ಸೈನ್-ಇನ್ ಜೊತೆಗೆ ಇಮೇಲ್ ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್‌ಗಳು ಜನಪ್ರಿಯ ಜೋಡಿ — ಯಾವುದೇ ಪಾಸ್‌ವರ್ಡ್ ಸಂಗ್ರಹಿಸದೆ ಹೆಚ್ಚಿನ ಜನರನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ.
ಇಮೇಲ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್
ನೀವು ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ನೀಡಿದರೆ, ಇವು ಕಡ್ಡಾಯ:
- ನಿಧಾನ ಪಾಸ್‌ವರ್ಡ್-ಹ್ಯಾಶಿಂಗ್ ಅಲ್ಗಾರಿದಮ್ ಬಳಸಿ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಹ್ಯಾಶ್ ಮಾಡಿ. OWASP ನ ಪಾಸ್‌ವರ್ಡ್ ಸಂಗ್ರಹಣಾ ಮಾರ್ಗದರ್ಶನ Argon2id ಅನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ, scrypt, bcrypt ಅಥವಾ PBKDF2 ಪರ್ಯಾಯಗಳು. ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ಸರಳ ಪಠ್ಯದಲ್ಲಿ ಅಥವಾ ವೇಗದ ಸಾಮಾನ್ಯ ಹ್ಯಾಶ್‌ನೊಂದಿಗೆ ಎಂದಿಗೂ ಸಂಗ್ರಹಿಸಬೇಡಿ.
- ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆ ಯಾದೃಚ್ಛಿಕ, ಒಂದು ಬಾರಿ ಬಳಸುವ, ಅವಧಿ ಮುಗಿಯುವ ಲಿಂಕ್ ಬಳಸುತ್ತದೆ, ಪರಿಶೀಲಿಸಲ್ಪಟ್ಟ ಇಮೇಲ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.
- ಯಾವ ಇಮೇಲ್‌ಗಳಿಗೆ ಖಾತೆಗಳಿವೆ ಎಂದು ಬಹಿರಂಗಪಡಿಸಬೇಡಿ. "ಈ ಇಮೇಲ್ ನೋಂದಾಯಿತವಾಗಿದ್ದರೆ, ಮರುಹೊಂದಿಕೆ ಲಿಂಕ್ ಕಳುಹಿಸಲಾಗಿದೆ" ಎಂಬುದು "ಯಾವುದೇ ಖಾತೆ ಕಂಡುಬಂದಿಲ್ಲ" ಗಿಂತ ಉತ್ತಮ.
- ಲಾಗಿನ್ ಮತ್ತು ಮರುಹೊಂದಿಕೆ ಪ್ರಯತ್ನಗಳಿಗೆ ದರ ಮಿತಿ ಹಾಕಿ ಪಾಸ್‌ವರ್ಡ್ ಊಹಿಸುವಿಕೆಯನ್ನು ನಿಧಾನಗೊಳಿಸಲು.
- ಉದ್ದ ಪಾಸ್‌ವರ್ಡ್‌ಗಳು ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್ ಮ್ಯಾನೇಜರ್‌ಗಳನ್ನು ಅನುಮತಿಸಿ; ವಿಚಿತ್ರ ಅಕ್ಷರ ಮಿಶ್ರಣಗಳನ್ನು ಬಲವಂತ ಮಾಡುವ ನಿಯಮಗಳನ್ನು ಬಿಡಿ.
ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್‌ಗಳು ಮತ್ತು ಒಂದು ಬಾರಿ ಕೋಡ್‌ಗಳು
ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್ ಬಳಕೆದಾರರಿಗೆ ಇಮೇಲ್ ಮಾಡಲಾದ ಸೈನ್-ಇನ್ ಲಿಂಕ್. ಅದರ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದರೆ ಅವರು ಲಾಗಿನ್ ಆಗುತ್ತಾರೆ. ಒಂದು ಬಾರಿ ಕೋಡ್ ಅದೇ ಕಲ್ಪನೆ, ಕ್ಲಿಕ್ ಮಾಡುವ ಬದಲು ಟೈಪ್ ಮಾಡಲಾಗುತ್ತದೆ.
- ಲಿಂಕ್‌ಗಳು ಮತ್ತು ಕೋಡ್‌ಗಳು ಬೇಗ ಅವಧಿ ಮುಗಿಯುತ್ತವೆ ಮತ್ತು ಒಂದು ಬಾರಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
- ಲಿಂಕ್ ಬಳಕೆದಾರರು ಕ್ಲಿಕ್ ಮಾಡಿದ ಸಾಧನದಲ್ಲೇ ಲಾಗಿನ್ ಮಾಡಬೇಕು, ಮತ್ತು ಟೋಕನ್ ಲಾಗ್‌ಗಳಲ್ಲಿ ಅಥವಾ ಅನಾಲಿಟಿಕ್ಸ್ ಪರಿಕರಗಳಲ್ಲಿ ಉಳಿಯಬಾರದು.
- ನಿಮಗೆ ವಿಶ್ವಾಸಾರ್ಹ ಇಮೇಲ್ ಕಳುಹಿಸುವಿಕೆ ಬೇಕು — ನಿಮ್ಮ ಆ್ಯಪ್‌ನಿಂದ ಇಮೇಲ್ ಕಳುಹಿಸುವುದು ಹೇಗೆ ನೋಡಿ. Gmail ಮತ್ತು Outlook ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ಸ್ಪ್ಯಾಮ್ ಫೋಲ್ಡರ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
Sign in with Google (ಮತ್ತು ಇತರ OAuth ಪ್ರೊವೈಡರ್‌ಗಳು)
"Sign in with Google" OAuth ಮತ್ತು OpenID Connect ಬಳಸುತ್ತದೆ: Google ಬಳಕೆದಾರ ಯಾರೆಂದು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಅವರ ಇಮೇಲ್ ಹಾಗೂ ಹೆಸರನ್ನು ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಹೇಳುತ್ತದೆ. ಸೆಪ್ಟೆಂಬರ್ 2026 ರಂತೆ ಸೆಟಪ್ Google Cloud Console ನ Google Auth Platform ವಿಭಾಗದಲ್ಲಿ ನಡೆಯುತ್ತದೆ:
- ಪ್ರಾಜೆಕ್ಟ್ ರಚಿಸಿ ಅಥವಾ ಆಯ್ಕೆ ಮಾಡಿ, ಮತ್ತು Branding ಪುಟ ಭರ್ತಿ ಮಾಡಿ — ಒಪ್ಪಿಗೆ ಪರದೆಯಲ್ಲಿ ಬಳಕೆದಾರರು ಏನು ನೋಡುತ್ತಾರೆ (ಆ್ಯಪ್ ಹೆಸರು, ಬೆಂಬಲ ಇಮೇಲ್, ಲೋಗೋ).
- Clients ಪುಟದಲ್ಲಿ "Web application" ಪ್ರಕಾರದ ಕ್ಲೈಂಟ್ ರಚಿಸಿ.
- Authorized JavaScript origins ಮತ್ತು redirect URIs ಸೇರಿಸಿ — ನಿಮ್ಮ ಆ್ಯಪ್ ಚಲಿಸುವ ನಿಖರ ವಿಳಾಸಗಳು ಮತ್ತು ಸೈನ್-ಇನ್ ನಂತರ Google ಬಳಕೆದಾರರನ್ನು ಹಿಂದಿರುಗಿಸುವ ವಿಳಾಸಗಳು.
- ಕ್ಲೈಂಟ್ ID ಮತ್ತು ಕ್ಲೈಂಟ್ ಸೀಕ್ರೆಟ್ ಅನ್ನು ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಸೀಕ್ರೆಟ್‌ಗಳಲ್ಲಿ ಉಳಿಸಿ.
Google ನ OAuth ದಸ್ತಾವೇಜು ಪ್ರಕಾರ ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಾಗುವ ವಿಷಯಗಳು:
redirect_uri_mismatch: ರೀಡೈರೆಕ್ಟ್ ವಿಳಾಸ ನಿಖರವಾಗಿ ಹೊಂದಬೇಕು,httpvshttps, ದೊಡ್ಡ-ಸಣ್ಣ ಅಕ್ಷರಗಳು ಮತ್ತು ಕೊನೆಯ ಸ್ಲ್ಯಾಶ್ ಸೇರಿದಂತೆ. ನಿಮ್ಮ ಪೂರ್ವವೀಕ್ಷಣೆ ವಿಳಾಸಕ್ಕೆ ಒಂದು ಮತ್ತು ನಿಮ್ಮ ಲೈವ್ ಡೊಮೇನ್‌ಗೆ ಒಂದು ಸೇರಿಸಿ.- HTTPS ಬೇಕು: ರೀಡೈರೆಕ್ಟ್ URI ಗಳು HTTPS ಬಳಸಬೇಕು, ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ
localhostಹೊರತುಪಡಿಸಿ. stateಪ್ಯಾರಾಮೀಟರ್ ಹಿಂದಿರುಗಿದಾಗ ಪರಿಶೀಲಿಸಬೇಕು, ಕ್ರಾಸ್-ಸೈಟ್ ವಿನಂತಿ ಫೋರ್ಜರಿಯಿಂದ ರಕ್ಷಿಸಲು. ಒಳ್ಳೆಯ ಲೈಬ್ರರಿಗಳು ಇದನ್ನು ನಿಮಗಾಗಿ ಮಾಡುತ್ತವೆ.
ನೀವು ಮೂಲ ಸೈನ್-ಇನ್ ಮಾಹಿತಿ (ಹೆಸರು, ಇಮೇಲ್, ಪ್ರೊಫೈಲ್) ಮಾತ್ರ ಕೇಳಿದರೆ, Google ಆ್ಯಪ್ ಪರಿಶೀಲನೆ ಕಡ್ಡಾಯವಲ್ಲ ಎನ್ನುತ್ತದೆ. ಬಳಕೆದಾರರ Gmail, Drive ಅಥವಾ Calendar ಗೆ ಪ್ರವೇಶ ಕೇಳುವುದು ಬೇರೆ ಮತ್ತು ಪರಿಶೀಲನೆ ಬೇಕು.
ಲೈಬ್ರರಿ ನಿರ್ಮಿಸಬೇಕೇ ಅಥವಾ ಪ್ರೊವೈಡರ್ ಬಳಸಬೇಕೇ?
| ವಿಧಾನ | ಉದಾಹರಣೆಗಳು | ಯಾವಾಗ ಸರಿಹೊಂದುತ್ತದೆ |
|---|---|---|
| ಹೋಸ್ಟ್ ಮಾಡಿದ ಆಥ್ ಪ್ರೊವೈಡರ್ | ಸೈನ್-ಇನ್, ಬಳಕೆದಾರ ನಿರ್ವಹಣೆ ಮತ್ತು ಸೆಷನ್‌ಗಳನ್ನು ನಿಮಗಾಗಿ ಹೋಸ್ಟ್ ಮಾಡುವ ಸೇವೆಗಳು | ಕಡಿಮೆ ಭದ್ರತಾ ಹೊಣೆಯೊಂದಿಗೆ ಬೇಗ ಲಾಗಿನ್ ಬೇಕಾದಾಗ |
| ನಿಮ್ಮ ಆ್ಯಪ್‌ನಲ್ಲಿ ಆಥ್ ಲೈಬ್ರರಿ | ನಿಮ್ಮ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಾಗಿ ಮುಕ್ತ ಮೂಲ ಲೈಬ್ರರಿಗಳು | ಬಳಕೆದಾರರು ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇರಬೇಕು ಮತ್ತು ಪ್ರತಿ-ಬಳಕೆದಾರ ಶುಲ್ಕ ಇರಬಾರದು ಎಂದು ಬಯಸಿದಾಗ |
| ನೀವೇ ಬರೆಯುವುದು | — | ಬಹುತೇಕ ಎಂದಿಗೂ. ಬಹಳ ಸೂಕ್ಷ್ಮ ವಿವರಗಳಿವೆ |
ಮೊದಲ ಎರಡೂ ಸಮಂಜಸ. ಹೋಸ್ಟ್ ಮಾಡಿದ ಪ್ರೊವೈಡರ್‌ಗಳು ಹೆಚ್ಚು ನಿಭಾಯಿಸುತ್ತಾರೆ ಆದರೆ ಅವಲಂಬನೆ ಸೇರಿಸುತ್ತಾರೆ ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಸಕ್ರಿಯ ಬಳಕೆದಾರರಿಗೆ ಶುಲ್ಕ ವಿಧಿಸುತ್ತಾರೆ; ಪ್ರಸ್ತುತ ಬೆಲೆಗಾಗಿ ಅವರ ಸೈಟ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಲೈಬ್ರರಿಗಳು ಎಲ್ಲವನ್ನೂ ನಿಮ್ಮ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇಡುತ್ತವೆ ಆದರೆ ಸರಿಯಾಗಿ ಸಂರಚಿಸಲು ನಿಮಗೆ ಹೆಚ್ಚು ಬಿಡುತ್ತವೆ. ನೀವು ಯಾವುದನ್ನೇ ಆರಿಸಿದರೂ, ಪಾಸ್‌ವರ್ಡ್ ಅಥವಾ ಸೆಷನ್ ತರ್ಕವನ್ನು ಕೈಯಿಂದ ಬರೆಯದೆ ಅದನ್ನು ಬಳಸಲು AI ಗೆ ಕೇಳಿ.
ಪಾತ್ರಗಳು ಮತ್ತು ಅನುಮತಿಗಳು
ಲಾಗಿನ್ ಯಾರೆಂದು ಹೇಳುತ್ತದೆ. ಅನುಮತಿಗಳು ಅವರು ಏನು ಮಾಡಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಆರಂಭದಲ್ಲಿ ಸರಳವಾಗಿಡಿ:
| ಪಾತ್ರ | ವಿಶಿಷ್ಟ ಅನುಮತಿಗಳು |
|---|---|
| ಭೇಟಿಗಾರ | ಸಾರ್ವಜನಿಕ ಪುಟಗಳನ್ನು ನೋಡುವುದು |
| ಸದಸ್ಯ / ಗ್ರಾಹಕ | ತಮ್ಮ ಸ್ವಂತ ದಾಖಲೆಗಳನ್ನು ನೋಡುವುದು ಮತ್ತು ಸಂಪಾದಿಸುವುದು |
| ಸಿಬ್ಬಂದಿ | ತಮ್ಮ ತಂಡ ಅಥವಾ ವ್ಯವಹಾರದ ಎಲ್ಲಾ ದಾಖಲೆಗಳನ್ನು ನೋಡುವುದು; ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಅಥವಾ ಬಿಲ್ಲಿಂಗ್ ಬದಲಿಸಲಾಗುವುದಿಲ್ಲ |
| ಮಾಲೀಕ / ಅಡ್ಮಿನ್ | ಎಲ್ಲವೂ, ಬಳಕೆದಾರರು ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ ಸೇರಿದಂತೆ |
ಪಾತ್ರದ ಹೆಸರುಗಳಿಗಿಂತ ಮುಖ್ಯವಾದ ನಿಯಮಗಳು:
- ಪ್ರತಿ ಬಾರಿಯೂ ಸರ್ವರ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ. ಪುಟದಲ್ಲಿ ಬಟನ್ ಮರೆಮಾಡುವುದು ಯಾರಾದರೂ API ನೇರವಾಗಿ ಕರೆಯುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ.
- ಮಾಲೀಕರ ಮೂಲಕ ವ್ಯಾಪ್ತಿ ನಿಗದಿ ಮಾಡಿ. "ಬುಕಿಂಗ್ 123" ಪಡೆಯುವ ಸದಸ್ಯರಿಗೆ ಅದು ತಮ್ಮದಾಗಿದ್ದರೆ ಮಾತ್ರ ಸಿಗಬೇಕು.
- ಬಳಕೆದಾರರು ತಮ್ಮನ್ನು ತಾವೇ ಬಡ್ತಿ ಮಾಡಲಾಗುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್ ನವೀಕರಣಗಳಲ್ಲಿ ಬ್ರೌಸರ್‌ನಿಂದ ಕಳುಹಿಸಿದ ಪಾತ್ರ ಕ್ಷೇತ್ರಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ.
- ಡೀಫಾಲ್ಟ್ ಆಗಿ ಪ್ರವೇಶ ನಿರಾಕರಿಸಿ. ನೀವು ನಿರ್ಧರಿಸದ ಹೊರತು ಹೊಸ ರೂಟ್‌ಗಳಿಗೆ ಲಾಗಿನ್ ಬೇಕು.
ಎರಡು ಖಾತೆಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ: ಒಂದರಲ್ಲಿ ಲಾಗಿನ್ ಆಗಿ, ದಾಖಲೆಯ ID ಗಮನಿಸಿ, ನಂತರ ಇನ್ನೊಂದರಲ್ಲಿ ಲಾಗಿನ್ ಆಗಿ ಅದನ್ನು ತೆರೆಯಲು ಪ್ರಯತ್ನಿಸಿ. ಸಂಪೂರ್ಣ ಪರೀಕ್ಷೆಗಾಗಿ ನಮ್ಮ ಭದ್ರತಾ ಪರಿಶೀಲನಾಪಟ್ಟಿ ನೋಡಿ.
ಸೆಷನ್ ಭದ್ರತೆ
ಲಾಗಿನ್ ನಂತರ, ಆ್ಯಪ್ ಸೆಷನ್ ಮೂಲಕ ಬಳಕೆದಾರರನ್ನು ನೆನಪಿಡುತ್ತದೆ — ಸಾಮಾನ್ಯವಾಗಿ ಕುಕಿ. OWASP ನ ಸೆಷನ್ ನಿರ್ವಹಣಾ ಮಾರ್ಗದರ್ಶನ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ:
- ಸೆಷನ್ ಕುಕಿಗಳು
Secure(HTTPS ಮಾತ್ರ),HttpOnly(ಪುಟ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ಓದಲಾಗದ) ಮತ್ತುSameSiteನೊಂದಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ - ಲಾಗಿನ್‌ನಲ್ಲಿ ಹೊಸ ಸೆಷನ್ ID ನೀಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಸವಲತ್ತುಗಳು ಬದಲಾದಾಗ ಮತ್ತೆ
- ನಿಷ್ಕ್ರಿಯ ಸಮಯ ಮಿತಿ ಮತ್ತು ಗರಿಷ್ಠ ಸಂಪೂರ್ಣ ಜೀವಿತಾವಧಿ, ಸರ್ವರ್‌ನಲ್ಲಿ ಜಾರಿಗೊಳಿಸಲಾಗಿದೆ
- ಲಾಗ್ಔಟ್ ಸೆಷನ್ ಅನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಅಂತ್ಯಗೊಳಿಸುತ್ತದೆ, ಕೇವಲ ಕುಕಿಯನ್ನು ಅಳಿಸುವುದಲ್ಲ
- ಬಳಕೆದಾರರು ಪಾಸ್‌ವರ್ಡ್ ಬದಲಿಸಿದಾಗ ಸೆಷನ್‌ಗಳು ಅಮಾನ್ಯವಾಗುತ್ತವೆ
ಲಾಗಿನ್ ಟೋಕನ್‌ಗಳನ್ನು ಬ್ರೌಸರ್‌ನ local storage ನಲ್ಲಿ ಇಡುವುದು ಟ್ಯುಟೋರಿಯಲ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ, ಆದರೆ ಅದು ಪುಟದಲ್ಲಿ ಚಲಿಸುವ ಯಾವುದೇ ಸ್ಕ್ರಿಪ್ಟ್‌ಗೆ ಅವುಗಳನ್ನು ತೆರೆದಿಡುತ್ತದೆ; ವೆಬ್ ಆ್ಯಪ್‌ಗಳಿಗೆ ಸುರಕ್ಷಿತ ಕುಕಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಉತ್ತಮ ಡೀಫಾಲ್ಟ್.
ಎಲ್ಲವನ್ನೂ ಒಳಗೊಳ್ಳುವ ಒಂದು ಪ್ರಾಂಪ್ಟ್
ಈ ಆ್ಯಪ್‌ಗೆ ಬಳಕೆದಾರ ಖಾತೆಗಳನ್ನು ಸೇರಿಸಿ. ಬಳಕೆದಾರರು ಇಮೇಲ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್‌ನೊಂದಿಗೆ ಸೈನ್ ಅಪ್ ಮತ್ತು ಲಾಗಿನ್ ಮಾಡಬಹುದು, ಅಥವಾ Google ನೊಂದಿಗೆ. ಕಸ್ಟಮ್ ಆಥ್ ಕೋಡ್ ಬದಲು [ಲೈಬ್ರರಿ ಅಥವಾ ಪ್ರೊವೈಡರ್] ಬಳಸಿ. ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು Argon2id ಅಥವಾ bcrypt ಬಳಸಿ ಹ್ಯಾಶ್ ಮಾಡಿ. ಇಮೇಲ್ ಮೂಲಕ ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಕೆ ಸೇರಿಸಿ, ಒಂದು ಗಂಟೆಯಲ್ಲಿ ಅವಧಿ ಮುಗಿಯುವ ಒಂದು ಬಾರಿ ಲಿಂಕ್‌ನೊಂದಿಗೆ. ಸುರಕ್ಷಿತ, HttpOnly ಕುಕಿಗಳಲ್ಲಿ ಸೆಷನ್‌ಗಳನ್ನು ಇಡಿ. /dashboard ಮತ್ತು ಪ್ರತಿ /api ರೂಟ್ ಅನ್ನು ರಕ್ಷಿಸಿ ಇದರಿಂದ ಲಾಗಿನ್ ಆದ ಬಳಕೆದಾರರು ಮಾತ್ರ ಬಳಸಬಹುದು, ಮತ್ತು ಬಳಕೆದಾರರು ತಮ್ಮ ಸ್ವಂತ ಪ್ರಾಜೆಕ್ಟ್‌ಗಳನ್ನು ಮಾತ್ರ ನೋಡಬಹುದು ಎಂದು ಖಚಿತಪಡಿಸಿ. ಎಲ್ಲಾ ಬಳಕೆದಾರರನ್ನು ನೋಡಬಹುದಾದ "admin" ಪಾತ್ರ ಸೇರಿಸಿ; ಅಡ್ಮಿನ್‌ಗಳು ಮಾತ್ರ /admin ತಲುಪಬಹುದು, ಸರ್ವರ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ.
ನಂತರ ಪರೀಕ್ಷಿಸಿ: ಸೈನ್ ಅಪ್ ಮಾಡಿ, ಲಾಗ್ಔಟ್ ಮಾಡಿ, ಲಾಗಿನ್ ಮಾಡಿ, ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಸಿ, ಲಾಗ್ಔಟ್ ಆಗಿರುವಾಗ ಖಾಸಗಿ URL ಪ್ರಯತ್ನಿಸಿ, ಮತ್ತು ಇನ್ನೊಬ್ಬ ಬಳಕೆದಾರರ ದಾಖಲೆ ಪ್ರಯತ್ನಿಸಿ.
AI-ನಿರ್ಮಿತ ಲಾಗಿನ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು
- ಪುಟದಲ್ಲಿ ಮಾತ್ರ ರಕ್ಷಣೆ. ಪುಟ ಲಾಗ್ಔಟ್ ಆದ ಬಳಕೆದಾರರನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ, ಆದರೆ API ಯಾರಿಗಾದರೂ ಡೇಟಾ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.
- ಸೀಕ್ರೆಟ್‌ಗಳು ಬ್ರೌಸರ್‌ನಲ್ಲಿ. OAuth ಕ್ಲೈಂಟ್ ಸೀಕ್ರೆಟ್‌ಗಳು ಮತ್ತು ಆಥ್ ಪ್ರೊವೈಡರ್ ಅಡ್ಮಿನ್ ಕೀಗಳು ಸರ್ವರ್‌ನಲ್ಲಿ ಇರಬೇಕು.
- ಪೂರ್ವವೀಕ್ಷಣೆ ಮತ್ತು ಲೈವ್ URL ಗಳು ಗೊಂದಲ. Google ನ ರೀಡೈರೆಕ್ಟ್ URI ಅಥವಾ ಮರುಹೊಂದಿಕೆ ಇಮೇಲ್ ಲಿಂಕ್ ಪೂರ್ವವೀಕ್ಷಣೆಗೆ ತೋರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಕಟಿಸಿದ ನಂತರ ಲಾಗಿನ್ ಮುರಿಯುತ್ತದೆ.
- ಇಮೇಲ್ ಪರಿಶೀಲನೆ ಇಲ್ಲ. ಯಾರಾದರೂ anyone@company.com ಆಗಿ ಸೈನ್ ಅಪ್ ಮಾಡಬಹುದು. ಆ ವಿಳಾಸಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ಯಾವುದೇ ಕೆಲಸ ನೀಡುವ ಮೊದಲು ಇಮೇಲ್ ಪರಿಶೀಲಿಸಿ.
- ಕೇವಲ ಸರಿಯಾದ ದಾರಿಯನ್ನು ಪರೀಕ್ಷಿಸುವುದು. ತಪ್ಪು ಪಾಸ್‌ವರ್ಡ್‌ಗಳು, ಅವಧಿ ಮುಗಿದ ಲಿಂಕ್‌ಗಳು ಮತ್ತು ಎರಡನೇ ಖಾತೆಯನ್ನು ಪ್ರಯತ್ನಿಸಿ.
Mythex ನಲ್ಲಿ ಲಾಗಿನ್ ಸೇರಿಸುವುದು
Mythex ನಲ್ಲಿ, ನಿಮ್ಮ ಆ್ಯಪ್‌ನ ಬಳಕೆದಾರರಿಗೆ ಲಾಗಿನ್ ನೀವು ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಸೇರಿಸುವಂತದ್ದು — ಅದು ನಿಮ್ಮ ಸ್ವಂತ Mythex ಖಾತೆಯಿಂದ ಪ್ರತ್ಯೇಕ. Mythex ಅಂತರ್ನಿರ್ಮಿತ ಆಥ್ ಉತ್ಪನ್ನ ಒದಗಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನೀವು ಆಥ್ ಲೈಬ್ರರಿ ಅಥವಾ ಪ್ರೊವೈಡರ್ ಮತ್ತು ಅದರ ಕೀಗಳನ್ನು ತರುತ್ತೀರಿ:
- ಒಂದು ವಿಧಾನ ಆರಿಸಿ — ಉದಾಹರಣೆಗೆ ನಿಮ್ಮ ಸ್ವಂತ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದ ಇಮೇಲ್ ಮತ್ತು ಪಾಸ್‌ವರ್ಡ್, ಅಥವಾ ಹೋಸ್ಟ್ ಮಾಡಿದ ಪ್ರೊವೈಡರ್‌ನ SDK.
- ನೀವೇ ಬಳಕೆದಾರರನ್ನು ಸಂಗ್ರಹಿಸಿದರೆ, ಆ್ಯಪ್‌ಗೆ ಡೇಟಾಬೇಸ್ ಬೇಕು; ಚಾಟ್‌ನಲ್ಲಿ ಕೇಳಿ ಅಥವಾ
/databaseಬಳಸಿ. - ಪ್ರೊವೈಡರ್ ಕೀಗಳನ್ನು ಪ್ರಾಜೆಕ್ಟ್ ಸೀಕ್ರೆಟ್‌ಗಳಲ್ಲಿ ಇರಿಸಿ (
/secretsಅಥವಾ ಪ್ರಾಜೆಕ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು). - ಮೇಲಿನಂತಹ ಪ್ರಾಂಪ್ಟ್ ಬಳಸಿ, ನಂತರ Preview ನಲ್ಲಿ ಪರೀಕ್ಷಿಸಿ. Google ಸೈನ್-ಇನ್‌ಗಾಗಿ, ನಿಮ್ಮ ಪೂರ್ವವೀಕ್ಷಣೆ ಮತ್ತು ಪ್ರಕಟಿತ ವಿಳಾಸ ಎರಡಕ್ಕೂ ರೀಡೈರೆಕ್ಟ್ URI ಗಳನ್ನು ಸೇರಿಸಿ.
ದಸ್ತಾವೇಜಿನಲ್ಲಿ ನಿಮ್ಮ ಆ್ಯಪ್‌ಗೆ ಲಾಗಿನ್ ಸೇರಿಸಿ ನೋಡಿ. ನೀವು ಪಾವತಿಸುವ ಉತ್ಪನ್ನ ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, SaaS MVP ನಿರ್ಮಿಸುವುದು ಹೇಗೆ ಖಾತೆಗಳು ಮತ್ತು ಬಿಲ್ಲಿಂಗ್ ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ವಿವರಿಸುತ್ತದೆ.
ಪ್ರಶ್ನೆಗಳು
ಆ್ಯಪ್‌ಗೆ ಸೇರಿಸಲು ಸುಲಭವಾದ ಲಾಗಿನ್ ಯಾವುದು?
ಹೋಸ್ಟ್ ಮಾಡಿದ ದೃಢೀಕರಣ ಪ್ರೊವೈಡರ್ ಅಥವಾ ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಆಥ್ ಲೈಬ್ರರಿ ಬಳಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸುಲಭ ಮತ್ತು ಸುರಕ್ಷಿತ, ಏಕೆಂದರೆ ಸೆಷನ್‌ಗಳು, ಪಾಸ್‌ವರ್ಡ್ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಮರುಹೊಂದಿಕೆ ಈಗಾಗಲೇ ನಿಭಾಯಿಸಲ್ಪಟ್ಟಿರುತ್ತವೆ. Google ಖಾತೆ ಇರುವ ಬಳಕೆದಾರರಿಗೆ Sign in with Google ಅತ್ಯಂತ ಕಡಿಮೆ ಅಡೆತಡೆಯ ಆಯ್ಕೆ.
ಮ್ಯಾಜಿಕ್ ಲಿಂಕ್‌ಗಳು ಪಾಸ್‌ವರ್ಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚು ಸುರಕ್ಷಿತವೇ?
ಅವು ಪಾಸ್‌ವರ್ಡ್ ಮರುಬಳಕೆ ಮತ್ತು ದುರ್ಬಲ ಪಾಸ್‌ವರ್ಡ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತವೆ, ಆದರೆ ಅಪಾಯವನ್ನು ಬಳಕೆದಾರರ ಇಮೇಲ್ ಖಾತೆಗೆ ವರ್ಗಾಯಿಸುತ್ತವೆ. ಲಿಂಕ್‌ಗಳು ಬೇಗ ಅವಧಿ ಮುಗಿಯಬೇಕು ಮತ್ತು ಒಂದು ಬಾರಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಬೇಕು. ಹೆಚ್ಚಿನ ಸಣ್ಣ ಆ್ಯಪ್‌ಗಳಿಗೆ ಇವು ಸಮಂಜಸ ಆಯ್ಕೆ, ಆಗಾಗ್ಗೆ Google ಸೈನ್ ಇನ್ ಜೊತೆಗೆ ನೀಡಲಾಗುತ್ತದೆ.
Sign in with Google ಸೇರಿಸಲು Googleನ ಅನುಮೋದನೆ ಬೇಕೇ?
ನೀವು ಕೇವಲ ಮೂಲ ಸೈನ್-ಇನ್ ಮಾಹಿತಿ (ಹೆಸರು, ಇಮೇಲ್ ಮತ್ತು ಪ್ರೊಫೈಲ್) ಕೇಳಿದರೆ, Google ಪರಿಶೀಲನೆ ಕಡ್ಡಾಯವಲ್ಲ ಎನ್ನುತ್ತದೆ, ಆದರೂ ನೀವು ಒಪ್ಪಿಗೆ ಪರದೆ ಮತ್ತು OAuth ಕ್ಲೈಂಟ್ ಸಂರಚಿಸಬೇಕು. Gmail ಅಥವಾ Drive ನಂತಹ ಸೂಕ್ಷ್ಮ ಡೇಟಾಗೆ ಪ್ರವೇಶ ಕೇಳಿದರೆ Googleನ ಆ್ಯಪ್ ಪರಿಶೀಲನೆ ಬೇಕು.
ಲಾಗಿನ್ ಮತ್ತು ಅನುಮತಿಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು?
ಲಾಗಿನ್ (ದೃಢೀಕರಣ) ಬಳಕೆದಾರ ಯಾರೆಂದು ದೃಢೀಕರಿಸುತ್ತದೆ. ಅನುಮತಿಗಳು (ಅಧಿಕಾರ) ಆ ಬಳಕೆದಾರ ಏನನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಮಾಡಬಹುದು ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಆ್ಯಪ್‌ಗೆ ಎರಡೂ ಬೇಕು, ಮತ್ತು ಅನುಮತಿಗಳನ್ನು ಪ್ರತಿ ವಿನಂತಿಯಲ್ಲೂ ಸರ್ವರ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸಬೇಕು.