> ## Documentation Index
> Fetch the complete documentation index at: https://generaltranslation.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# सर्वोत्तम तरीके

export const Button = ({href, children}) => {
  return <div className="not-prose group">
    <a href={href}>
      <button className="flex items-center space-x-2.5 py-1 px-4 bg-primary-dark dark:bg-white text-white dark:text-gray-950 rounded-full group-hover:opacity-[0.9] font-medium">
        <span>
          {children}
        </span>
        <svg width="3" height="24" viewBox="0 -9 3 24" class="h-6 rotate-0 overflow-visible"><path d="M0 0L3 3L0 6" fill="none" stroke="currentColor" stroke-width="1.5" stroke-linecap="round"></path></svg>
      </button>
    </a>
  </div>;
};

आपकी API keys और tokens को बहुत सावधानी से सुरक्षित रखना चाहिए। 

ये credentials सीधे आपके [developer ऐप](/hi/resources/fundamentals/developer-apps) और उन X खातों से जुड़े होते हैं जिन्होंने आपको उनकी ओर से requests करने की अनुमति दी है। अगर आपकी keys से समझौता हो जाता है, तो दुर्भावनापूर्ण तत्व उनका इस्तेमाल आपके developer ऐप या उसके अधिकृत उपयोगकर्ताओं की ओर से X endpoints पर requests करने के लिए कर सकते हैं। इसका मतलब यह हो सकता है कि उन requests की वजह से आप अनपेक्षित रेट लिमिट्स तक पहुँच जाएँ, अपने paid access allotment का उपयोग कर लें, या यहाँ तक कि आपका developer ऐप निलंबित हो जाए।

निम्नलिखित अनुभागों में कुछ सर्वोत्तम प्रथाएँ दी गई हैं, जिन पर अपनी API keys और tokens का प्रबंधन करते समय विचार किया जाना चाहिए।

<div id="regenerate-api-keys-and-tokens">
  ## API keys और tokens को फिर से जनरेट करें
</div>

अगर आपको लगता है कि आपके API keys उजागर हो गए हैं, तो नीचे दिए गए चरणों का पालन करके आपको अपने API keys फिर से जनरेट करने चाहिए:

1. [Developer Console के "Apps" पेज](https://developer.x.com/en/portal/projects-and-apps.html) पर जाएँ।
2. संबंधित ऐप के बगल में मौजूद "Keys and tokens" आइकॉन (🗝 ) पर क्लिक करें।
3. keys और tokens के उस सेट के बगल में मौजूद "Regenerate" बटन पर क्लिक करें, जिसे आप फिर से जनरेट करना चाहते हैं। 

अगर आप अपने Access Tokens या बेयरर टोकन को प्रोग्रामेटिक तरीके से फिर से जनरेट करना चाहते हैं, तो आप हमारे authentication endpoints का उपयोग करके ऐसा कर सकते हैं।

* अगर आप अपने Access Tokens फिर से जनरेट करना चाहते हैं, तो पहले [POST oauth/invalidate\_token](/hi/resources/fundamentals/authentication/api-reference#post-oauth2-invalidate-token) endpoint का उपयोग करके अपने tokens को अमान्य करना होगा, फिर [3-legged OAuth flow](/hi/resources/fundamentals/authentication/oauth-1-0a/obtaining-user-access-tokens) का उपयोग करके उन्हें फिर से जनरेट करना होगा।
* अगर आप अपना बेयरर टोकन फिर से जनरेट करना चाहते हैं, तो पहले [POST oauth2/invalidate\_token](/hi/resources/fundamentals/authentication/api-reference#post-oauth2-invalidate-token) endpoint का उपयोग करके अपने token को अमान्य करना होगा, फिर [POST oauth2/token](/hi/resources/fundamentals/authentication/api-reference#post-oauth2-token) endpoint का उपयोग करके उसे फिर से जनरेट करना होगा।

<div id="having-a-central-file-for-your-secrets">
  ## अपने secrets के लिए एक केंद्रीय फ़ाइल रखना
</div>

आपके secrets को रखने के लिए .ENV फ़ाइल या किसी अन्य प्रकार की .yaml फ़ाइल जैसी किसी फ़ाइल का उपयोग करना एक उपयोगी विकल्प हो सकता है, लेकिन यह सुनिश्चित करें कि आपके पास एक मज़बूत .gitignore फ़ाइल हो, ताकि आप इन्हें गलती से किसी git repository में commit न कर दें। 

<div id="environment-variables">
  ## पर्यावरण वेरिएबल
</div>

पर्यावरण वेरिएबल का उपयोग करने वाला कोड लिखना उपयोगी हो सकता है। 

इसका एक उदाहरण नीचे Python में दिया गया है:

```python theme={null}
import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")
```

अपने टर्मिनल में आपको कुछ इस तरह लिखना चाहिए:

```bash theme={null}
export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'
```

<div id="source-code-and-version-control">
  ## स्रोत कोड और संस्करण नियंत्रण
</div>

डेवलपरों द्वारा की जाने वाली सबसे आम सुरक्षा गलतियों में से एक यह है कि API keys और tokens को GitHub और BitBucket जैसे सुलभ version control systems में source code के साथ commit कर दिया जाता है। इनमें से कई code repositories सार्वजनिक रूप से उपलब्ध होती हैं। यह गलती सार्वजनिक code repositories में इतनी बार की जाती है कि API keys खोजने के लिए उन्हें scrape करने वाले लाभदायक bots तक मौजूद हैं।

* सर्वर पर्यावरण वेरिएबल का उपयोग करें। API keys को पर्यावरण वेरिएबल में संग्रहीत करके, आप उन्हें अपने code और version control से बाहर रखते हैं। इससे आप अलग-अलग environments के लिए अलग-अलग keys का आसानी से उपयोग भी कर सकते हैं।
* ऐसी configuration file का उपयोग करें जिसे source control से बाहर रखा गया हो। फ़ाइल को version control द्वारा track किए जाने से बाहर रखने के लिए filename को अपनी [.gitignore](https://git-scm.com/docs/gitignore) file में जोड़ें।
* यदि version control का उपयोग करने के बाद आप अपने code से API keys हटा देते हैं, तो संभव है कि आपके codebase के पुराने versions तक पहुँचकर वे API keys अब भी उपलब्ध हों। अगले section में बताए अनुसार अपनी API keys को फिर से generate करें।

<div id="databases">
  ## डेटाबेस
</div>

यदि आपको अपने access tokens को किसी डेटाबेस में संग्रहीत करना हो, तो कृपया निम्नलिखित बातों का ध्यान रखें:

* डेटाबेस तक पहुंच को इस तरह सीमित करें कि access tokens केवल token के स्वामी द्वारा ही पढ़े जा सकें।
* access tokens के लिए डेटाबेस तालिका पर संपादन/लेखन विशेषाधिकार सीमित करें - इसे key management system के साथ स्वचालित किया जाना चाहिए।
* किसी भी data store में संग्रहीत करने से पहले access tokens को एन्क्रिप्ट करें।

<div id="password-management-tools">
  ## पासवर्ड प्रबंधन टूल
</div>

1password या Last Pass जैसे पासवर्ड प्रबंधन टूल आपकी keys और tokens को सुरक्षित स्थान पर रखने में मददगार हो सकते हैं। आपको इन्हें किसी साझा टीम पासवर्ड प्रबंधन टूल में साझा करने से बचना चाहिए।

<div id="web-storage-cookies">
  ## वेब स्टोरेज और कुकीज़
</div>

वेब स्टोरेज के दो प्रकार होते हैं: LocalStorage और SessionStorage। इन्हें Cookies के उपयोग के बेहतर विकल्प के रूप में बनाया गया था, क्योंकि वेब स्टोरेज की संग्रहण क्षमता Cookie स्टोरेज की तुलना में कहीं अधिक होती है। हालांकि, इन दोनों स्टोरेज विकल्पों के अपने-अपने फायदे और नुकसान हैं।
 

**वेब स्टोरेज: LocalStorage**

लोकल वेब स्टोरेज में संग्रहीत कोई भी चीज़ स्थायी रहती है। इसका मतलब है कि डेटा तब तक बना रहता है, जब तक उसे स्पष्ट रूप से हटाया न जाए। आपके प्रोजेक्ट की ज़रूरतों के आधार पर, आप इसे एक सकारात्मक बात मान सकते हैं। हालांकि, LocalStorage का उपयोग करते समय आपको सावधान रहना चाहिए, क्योंकि डेटा में किए गए कोई भी बदलाव/जोड़ संबंधित वेबपेज पर भविष्य में होने वाली सभी विज़िट में उपलब्ध रहेंगे। हम आम तौर पर LocalStorage के उपयोग की सलाह नहीं देते, हालांकि इसके कुछ अपवाद हो सकते हैं। अगर आप LocalStorage का उपयोग करने का निर्णय लेते हैं, तो यह जानना उपयोगी है कि यह same-origin policy का समर्थन करता है, इसलिए यहाँ संग्रहीत सारा डेटा केवल उसी origin के माध्यम से उपलब्ध होगा। LocalStorage का एक अतिरिक्त प्रदर्शन लाभ यह है कि client-server ट्रैफ़िक कम हो जाता है, क्योंकि हर HTTP request के लिए डेटा को सर्वर पर वापस भेजने की ज़रूरत नहीं होती।
 

**वेब स्टोरेज: SessionStorage**

SessionStorage, LocalStorage के समान है, लेकिन मुख्य अंतर यह है कि SessionStorage स्थायी नहीं होता। जिस window (या tab, यह इस पर निर्भर करता है कि आप कौन-सा browser उपयोग कर रहे हैं) का उपयोग SessionStorage में लिखने के लिए किया गया था, उसके बंद होते ही डेटा खो जाएगा। यह किसी उपयोगकर्ता सत्र के भीतर आपके token तक read access को सीमित करने में उपयोगी है। सुरक्षा के लिहाज़ से, आम तौर पर SessionStorage का उपयोग LocalStorage की तुलना में अधिक बेहतर माना जाता है। LocalStorage की तरह, same-origin policy support और client-server ट्रैफ़िक में कमी के लाभ SessionStorage पर भी लागू होते हैं।
 

**Cookies**

Cookies, session data को संग्रहीत करने का अधिक पारंपरिक तरीका हैं। आप प्रत्येक cookie के लिए एक expiration time सेट कर सकते हैं, जिससे उसे revoke करना और access सीमित करना आसान हो जाता है। हालांकि, cookies का उपयोग करने पर client-server ट्रैफ़िक निश्चित रूप से बढ़ जाएगा, क्योंकि हर HTTP request के लिए डेटा सर्वर पर वापस भेजा जाता है। यदि आप cookies का उपयोग करने का निर्णय लेते हैं, तो आपको session hijacking से सुरक्षा करनी होगी। डिफ़ॉल्ट रूप से, cookies को HTTP पर plaintext में भेजा जाता है, जिससे उनकी सामग्री packet sniffing और/या man-in-the-middle attacks के प्रति संवेदनशील हो जाती है, जहाँ हमलावर आपके ट्रैफ़िक में बदलाव कर सकते हैं। ट्रांज़िट के दौरान अपने डेटा की सुरक्षा के लिए आपको हमेशा HTTPS लागू करना चाहिए। इससे confidentiality, integrity (डेटा की), और authentication मिलेंगे। हालांकि, अगर आपका web application या site HTTP और HTTPS दोनों के माध्यम से उपलब्ध है, तो आपको cookie पर 'Secure' flag का भी उपयोग करना चाहिए। यह हमलावरों को किसी उपयोगकर्ता को आपकी site के HTTP संस्करण का लिंक भेजने और उसके परिणामस्वरूप जनरेट हुई HTTP request को सुनने से रोकेगा।

Cookies का उपयोग करते समय session hijacking के विरुद्ध एक और द्वितीयक सुरक्षा उपाय यह है कि किसी भी high-impact action को करने से पहले उपयोगकर्ता की पहचान का फिर से सत्यापन किया जाए। आपकी cookies की सुरक्षा बेहतर करने के लिए विचार करने योग्य एक और flag 'HttpOnly' flag है। यह flag browser को बताता है कि संबंधित cookie केवल निर्दिष्ट server से ही एक्सेस की जा सकेगी। client-side scripts द्वारा किए गए किसी भी प्रयास को यह flag प्रतिबंधित कर देगा, जिससे अधिकांश cross-site scripting (XSS) attacks से सुरक्षा में मदद मिलेगी।