গুগল ডেটা প্রোটোকলে প্রমাণীকরণ এবং অনুমোদন

সতর্কতা : এই পৃষ্ঠাটি গুগলের পুরোনো এপিআই, গুগল ডেটা এপিআই সম্পর্কে; এটি শুধুমাত্র গুগল ডেটা এপিআই ডিরেক্টরিতে তালিকাভুক্ত এপিআইগুলির জন্য প্রাসঙ্গিক, যার মধ্যে অনেকগুলি নতুন এপিআই দিয়ে প্রতিস্থাপিত হয়েছে। একটি নির্দিষ্ট নতুন এপিআই সম্পর্কে তথ্যের জন্য, নতুন এপিআইয়ের ডকুমেন্টেশন দেখুন। একটি নতুন এপিআই দিয়ে অনুরোধ অনুমোদন সম্পর্কে তথ্যের জন্য, গুগল অ্যাকাউন্টস প্রমাণীকরণ এবং অনুমোদন দেখুন।

তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিকে প্রায়শই নির্দিষ্ট ধরণের কার্যকলাপের জন্য ব্যবহারকারীর Google অ্যাকাউন্টে সীমিত অ্যাক্সেসের প্রয়োজন হয়। ব্যবহারকারীর ডেটার অপব্যবহার না করার জন্য, অ্যাক্সেসের জন্য সমস্ত অনুরোধ অ্যাকাউন্টধারীর দ্বারা অনুমোদিত হতে হবে। অ্যাক্সেস নিয়ন্ত্রণের দুটি উপাদান রয়েছে, প্রমাণীকরণ এবং অনুমোদন।

প্রমাণীকরণ পরিষেবা ব্যবহারকারীদের একটি Google অ্যাকাউন্ট ব্যবহার করে আপনার অ্যাপ্লিকেশনে সাইন ইন করার অনুমতি দেয়।

অনুমোদন পরিষেবা ব্যবহারকারীদের আপনার অ্যাপ্লিকেশনটিকে Google অ্যাপ্লিকেশনগুলিতে সংরক্ষিত ডেটাতে অ্যাক্সেস প্রদান করতে দেয়। Google গোপনীয়তাকে গুরুত্ব সহকারে নেয় এবং যেকোনো অ্যাপ্লিকেশন যার জন্য ব্যবহারকারীর ডেটাতে অ্যাক্সেসের প্রয়োজন হয় তাকে ব্যবহারকারী কর্তৃক অনুমোদিত হতে হবে।

প্রমাণীকরণ এবং অনুমোদন পরিষেবাগুলিকে প্রায়শই সম্মিলিতভাবে auth বলা হয়।

Google API-এর প্রমাণীকরণ এবং অনুমোদনের মাধ্যমে তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি নির্দিষ্ট ধরণের কার্যকলাপের জন্য ব্যবহারকারীর Google অ্যাকাউন্টে সীমিত অ্যাক্সেস পেতে পারে। এই নথিতে উপলব্ধ প্রমাণীকরণ প্রক্রিয়াগুলি উপস্থাপন করা হয়েছে এবং প্রতিটি আপনার অ্যাপ্লিকেশনের জন্য কী কী প্রদান করে তা বর্ণনা করা হয়েছে।

  • গুগল সাইন-ইন একটি সহজ উপায় প্রদান করে যাতে লোকেরা তাদের গুগল শংসাপত্র ব্যবহার করে আপনার সাইটে সাইন-ইন করতে পারে। এতে এমন কিছু সরঞ্জাম রয়েছে যা বিভিন্ন ডিভাইসে সহজেই সংহত করা যায়।
  • OAuth 2.0 হল সমস্ত Google API-এর জন্য একটি অনুমোদন প্রোটোকল। OAuth 2.0 আপনার অ্যাপ্লিকেশনকে সরাসরি ক্রিপ্টোগ্রাফিক স্বাক্ষর করার প্রয়োজনের পরিবর্তে সুরক্ষার জন্য SSL-এর উপর নির্ভর করে। এই প্রোটোকলটি আপনার অ্যাপ্লিকেশনকে ব্যবহারকারীর Google অ্যাকাউন্টের সাথে সম্পর্কিত ডেটা অ্যাক্সেসের অনুরোধ করতে দেয়।
  • OAuth 2.0 ( OpenID Connect ) দিয়ে লগইন করলে ব্যবহারকারীরা তাদের Google অ্যাকাউন্ট দিয়ে লগ ইন করতে পারবেন। এটি OpenID এর বিকল্প, এবং OpenID ব্যবহারকারীদের OAuth 2.0 দিয়ে লগইন করার পরিকল্পনা করা উচিত।

যদি আপনার অ্যাপ্লিকেশনটি একটি গ্যাজেট হয় (iGoogle বা অন্যান্য OpenSocial কন্টেইনারে ব্যবহারের জন্য), তাহলে গ্যাজেটের জন্য প্রমাণীকরণ বিভাগটি দেখুন।

দ্রষ্টব্য : এই ডকুমেন্টটি প্রতিটি প্রমাণীকরণ পদ্ধতির একটি সারসংক্ষেপ প্রদানের উদ্দেশ্যে তৈরি। প্রতিটি পদ্ধতি সম্পর্কে বিস্তারিত তথ্যের জন্য, সম্পূর্ণ Google অ্যাকাউন্ট প্রমাণীকরণ API ডকুমেন্টেশন দেখুন।

গুগল অ্যাকাউন্টস এপিআই ব্যবহার সম্পর্কে আলোচনার জন্য গুগল অ্যাকাউন্টস এপিআই গ্রুপটিও দেখুন।

OAuth - ওয়েব এবং ইনস্টল করা অ্যাপ্লিকেশনের জন্য অনুমোদন

অনেক Google পরিষেবা ব্যবহারকারীর দ্বারা অনুমোদিত হলে, ব্যবহারকারীর তৈরি ডেটা, যেমন ক্যালেন্ডার বা ডকুমেন্টস ডেটা, তৃতীয় পক্ষের অ্যাক্সেসের অনুমতি দেয়। এই বৈশিষ্ট্যটি ব্যবহারকারীদের বিভিন্ন উদ্দেশ্যে তাদের Google অ্যাপ্লিকেশন এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনের মধ্যে ডেটা ভাগ এবং বিনিময় করতে দেয়।

ব্যবহারকারীর গুগল ডেটাতে অনুমোদিত অ্যাক্সেস পাওয়ার জন্য গুগল OAuth এর দুটি সংস্করণ সমর্থন করে: OAuth 1.0 এবং OAuth 2.0, উভয়ই ওয়েব অ্যাপ্লিকেশন এবং ইনস্টল করা অ্যাপ্লিকেশন উভয়ের অ্যাক্সেস প্রদান করে।

ওয়েব এবং ইনস্টল করা অ্যাপ্লিকেশনের জন্য OAuth 2.0

ওয়েব অ্যাপ্লিকেশন বা ইনস্টল করা অ্যাপ্লিকেশনগুলি নতুন, সরলীকৃত OAuth 2.0 প্রোটোকল ব্যবহার করে Google অ্যাকাউন্টের সাথে সম্পর্কিত ডেটাতে অ্যাক্সেস অনুমোদন করতে পারে। Google এর সাথে OAuth 2.0 কীভাবে বাস্তবায়ন করবেন তার বিশদ এবং উদাহরণের জন্য, OAuth 2.0 সম্পর্কে আমাদের ডকুমেন্টেশন দেখুন।

ওয়েব অ্যাপ্লিকেশনের জন্য OAuth 1.0

যেসব ওয়েব অ্যাপ্লিকেশনের গুগল অ্যাকাউন্ট বা গুগল অ্যাপস অ্যাকাউন্টের সাথে সম্পর্কিত ডেটাতে অনুমোদিত অ্যাক্সেসের প্রয়োজন হয়, তারা গুগলের OAuth API বাস্তবায়ন ব্যবহার করতে পারে। ওয়েব-ভিত্তিক অ্যাপ্লিকেশনের জন্য OAuth বাস্তবায়ন সম্পর্কে সম্পূর্ণ তথ্যের জন্য, উদাহরণ সহ, ওয়েব অ্যাপসের জন্য OAuth নির্দেশিকাটি দেখুন, অথবা এই নথিতে ওভারভিউ দেখুন।

ইনস্টল করা অ্যাপ্লিকেশনের জন্য OAuth 1.0

ব্যবহারকারীর কম্পিউটার এবং মোবাইল ডিভাইসে ইনস্টল করা অ্যাপ্লিকেশনগুলি Google অ্যাকাউন্টের সাথে সম্পর্কিত ডেটাতে অ্যাক্সেস অনুমোদনের জন্য OAuth ব্যবহার করতে পারে। ইনস্টল করা অ্যাপ্লিকেশনগুলির জন্য OAuth বাস্তবায়ন সম্পর্কে সম্পূর্ণ তথ্যের জন্য, ইনস্টল করা অ্যাপ্লিকেশনগুলির জন্য OAuth নির্দেশিকা দেখুন, অথবা এই নথিতে ওভারভিউ দেখুন।

ওয়েব অ্যাপ্লিকেশনের সাথে OAuth ব্যবহার করা

সকল গুগল ডেটা এপিআই OAuth সমর্থন করে, যা ওয়েব অ্যাপ্লিকেশনগুলিতে ডেটা ব্যবহারের অনুমোদনের জন্য একটি উন্মুক্ত মান। OAuth অনুরোধকারী সকল ওয়েব অ্যাপ্লিকেশনকে একটি নিরাপত্তা শংসাপত্র আপলোড করতে হবে এবং Google-এ নিবন্ধন করতে হবে। আরও তথ্যের জন্য ওয়েব-ভিত্তিক অ্যাপ্লিকেশনগুলির জন্য নিবন্ধন দেখুন।

Google Data APIs ক্লায়েন্ট লাইব্রেরিগুলি আপনার ওয়েব অ্যাপ্লিকেশনে OAuth ব্যবহারে সাহায্য করার জন্য পদ্ধতি প্রদান করে। বিশেষ করে, অনুরোধ টোকেন তৈরি করার, অনুরোধ টোকেন অনুমোদন করার এবং অ্যাক্সেস টোকেনের জন্য অনুমোদিত অনুরোধ টোকেন বিনিময় করার পদ্ধতি রয়েছে। লাইব্রেরিগুলি Google Data পরিষেবাতে অনুরোধ করার সময় প্রয়োজনীয় স্বাক্ষর অ্যালগরিদমগুলিও পরিচালনা করে। Google Data API ক্লায়েন্ট লাইব্রেরির সাথে OAuth কীভাবে ব্যবহার করবেন তার বিস্তৃত উদাহরণের জন্য, Google Data APIs ক্লায়েন্ট লাইব্রেরির সাথে OAuth ব্যবহার করা দেখুন।

OAuth অনুমোদন প্রক্রিয়া

OAuth অনুমোদন প্রক্রিয়ায় আপনার ওয়েব অ্যাপ্লিকেশন, Google এর অনুমোদন সার্ভার এবং শেষ ব্যবহারকারীর মধ্যে একাধিক মিথস্ক্রিয়া জড়িত।

মৌলিক স্তরে, প্রক্রিয়াটি নিম্নরূপ:

  1. আপনার অ্যাপ্লিকেশনটি অ্যাক্সেসের অনুরোধ করে এবং Google এর অনুমোদন সার্ভার থেকে একটি অননুমোদিত অনুরোধ টোকেন পায়।
  2. গুগল ব্যবহারকারীর কাছে আপনাকে প্রয়োজনীয় ডেটা অ্যাক্সেস দেওয়ার জন্য অনুরোধ করে।
  3. আপনার অ্যাপ্লিকেশনটি অনুমোদন সার্ভার থেকে একটি অনুমোদিত অনুরোধ টোকেন পায়।
  4. আপনি অনুমোদিত অনুরোধ টোকেনটি একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করেন।
  5. আপনি Google এর পরিষেবা অ্যাক্সেস সার্ভার থেকে ডেটা অনুরোধ করতে অ্যাক্সেস টোকেন ব্যবহার করেন।

যখন আপনার অ্যাপ্লিকেশনটি প্রাথমিকভাবে কোনও ব্যবহারকারীর ডেটা অ্যাক্সেসের অনুরোধ করে, তখন Google আপনার অ্যাপ্লিকেশনটিতে একটি অননুমোদিত অনুরোধ টোকেন জারি করে।

যদি ব্যবহারকারী ইতিমধ্যে লগ ইন না করে থাকেন, তাহলে গুগল ব্যবহারকারীকে লগ ইন করতে অনুরোধ করে। এরপর গুগল একটি অনুমোদন পৃষ্ঠা প্রদর্শন করে যা ব্যবহারকারীকে আপনার অ্যাপ্লিকেশন কোন গুগল পরিষেবা ডেটা অ্যাক্সেসের জন্য অনুরোধ করছে তা দেখতে দেয়।

যদি ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস অনুরোধ অনুমোদন করে, তাহলে Google একটি অনুমোদিত অনুরোধ টোকেন জারি করে। প্রতিটি অনুরোধ টোকেন শুধুমাত্র এক ঘন্টার জন্য বৈধ। শুধুমাত্র একটি অনুমোদিত অনুরোধ টোকেন একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করা যেতে পারে এবং এই বিনিময়টি প্রতিটি অনুমোদিত অনুরোধ টোকেনের জন্য শুধুমাত্র একবার করা যেতে পারে।

ডিফল্টরূপে, অ্যাক্সেস টোকেনগুলি দীর্ঘস্থায়ী হয়। প্রতিটি অ্যাক্সেস টোকেন অনুমোদনের জন্য মূল অনুরোধে নির্দিষ্ট ব্যবহারকারীর অ্যাকাউন্টের সাথে নির্দিষ্ট, এবং শুধুমাত্র সেই অনুরোধে নির্দিষ্ট পরিষেবাগুলিতে অ্যাক্সেস মঞ্জুর করে। আপনার অ্যাপ্লিকেশনটিতে অ্যাক্সেস টোকেনটি নিরাপদে সংরক্ষণ করা উচিত, কারণ এটি ব্যবহারকারীর ডেটাতে সমস্ত অ্যাক্সেসের জন্য প্রয়োজনীয়।

OAuth-এর জন্য প্রস্তুতি নেওয়া হচ্ছে

OAuth-এর মাধ্যমে Google অনুমোদন পরিষেবা ব্যবহার করার জন্য আপনার অ্যাপ্লিকেশন সেট আপ করার আগে, আপনাকে নিম্নলিখিত কাজগুলি সম্পন্ন করতে হবে।

আপনার ওয়েব অ্যাপ্লিকেশন নিবন্ধন করবেন কিনা তা সিদ্ধান্ত নেওয়া

আপনার ব্যবহারকারীদের তাদের ডেটার নিরাপত্তার অতিরিক্ত নিশ্চয়তা প্রদানের জন্য, আপনি Google-এ আপনার ওয়েব অ্যাপ্লিকেশন নিবন্ধন করতে পারেন এবং নিবন্ধিত সুরক্ষা শংসাপত্র দিয়ে আপনার অনুরোধগুলিতে স্বাক্ষর করতে পারেন। কিছু Google ডেটা API ফিড শুধুমাত্র নিবন্ধিত অ্যাপ্লিকেশনগুলির জন্য উপলব্ধ। আপনার আগ্রহী Google ডেটা API-এর ডকুমেন্টেশন দেখুন এবং নির্ধারণ করুন যে সেই API শুধুমাত্র নিবন্ধিত অ্যাপ্লিকেশনগুলির সাথে কাজ করে কিনা।

আপনার আবেদনপত্রে প্রতিটি OAuth অনুরোধে স্বাক্ষর করতে হবে। যদি আপনি আপনার অনুরোধগুলিতে স্বাক্ষর করার জন্য RSA-SHA1 স্বাক্ষর ব্যবহার করতে চান, তাহলে নিবন্ধন প্রক্রিয়ার অংশ হিসেবে আপনাকে একটি নিরাপত্তা শংসাপত্র আপলোড করতে হবে।

বিকল্পভাবে, আপনি আপনার অনুরোধগুলিতে স্বাক্ষর করার জন্য একটি HMAC-SHA1 স্বাক্ষর ব্যবহার করতে পারেন। HMAC-SHA1 স্বাক্ষরের জন্য কোনও শংসাপত্রের প্রয়োজন নেই। পরিবর্তে, Google একটি OAuth consumer secret মান তৈরি করে, যা আপনি নিবন্ধন করার পরে আপনার ডোমেনের নিবন্ধন পৃষ্ঠায় প্রদর্শিত হয়।

নিবন্ধন প্রক্রিয়া সম্পর্কে আরও তথ্যের জন্য, ওয়েব অ্যাপ্লিকেশনের জন্য নিবন্ধন দেখুন।

আপনার অ্যাপ্লিকেশন কোন ডেটা অ্যাক্সেস করবে তার পরিধি নির্ধারণ করা

প্রতিটি গুগল পরিষেবা গুগল ডেটা এপিআই-এর মাধ্যমে তাদের অ্যাক্সেসের সীমা নির্ধারণ করে। এই অ্যাক্সেসকে স্কোপ মান হিসেবে প্রকাশ করা হয়। কিছু পরিষেবা বিভিন্ন স্কোপ মান প্রদান করে, যার মাধ্যমে ব্যবহারকারীরা কোন অ্যাপ্লিকেশনের কোন ডেটাতে অ্যাক্সেস থাকা উচিত তা বেছে নিতে পারেন। আপনি যে গুগল পরিষেবাটি অ্যাক্সেস করতে চান তার জন্য উপলব্ধ স্কোপ মান সম্পর্কে তথ্যের জন্য, সেই পরিষেবার ডকুমেন্টেশন দেখুন।

সাধারণভাবে, আপনার প্রয়োজনীয় ডেটা সহ সবচেয়ে সংকীর্ণ স্কোপের জন্য একটি টোকেনের অনুরোধ করা উচিত। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশনটির ব্যবহারকারীর "সমস্ত ক্যালেন্ডার" ফিডে অ্যাক্সেসের প্রয়োজন হয়, তাহলে আপনার স্কোপের জন্য একটি টোকেনের অনুরোধ করা উচিত http://www.google.com/calendar/feeds/default/allcalendars/full ।

OAuth টোকেন পরিচালনা করার জন্য একটি প্রক্রিয়া স্থাপন করা হচ্ছে

যখন আপনি কোনও ব্যবহারকারীর ডেটার জন্য OAuth অ্যাক্সেস টোকেন পান, তখন ব্যবহারকারীর পক্ষ থেকে নির্দিষ্ট Google পরিষেবার সাথে ভবিষ্যতের সমস্ত ইন্টারঅ্যাকশনের জন্য আপনাকে সেই অ্যাক্সেস টোকেনটি ব্যবহার করতে হবে।

আপনার অ্যাপ্লিকেশনটি টোকেন স্টোরেজ নিরাপদে পরিচালনা করবে, যার মধ্যে প্রতিটি টোকেন বৈধ এমন Google পরিষেবা ট্র্যাক করা অন্তর্ভুক্ত। যদি আপনার একাধিক Google পরিষেবা অ্যাক্সেসের প্রয়োজন হয়, তাহলে আপনি একাধিক অ্যাক্সেস টোকেন পেতে পারেন, তবে প্রতি ব্যবহারকারী এবং অ্যাপ্লিকেশনের জন্য দশটির বেশি অ্যাক্সেস টোকেন যেকোনো সময় বকেয়া থাকতে পারে না।

যদি আপনার অ্যাপ্লিকেশন একাধিক ব্যবহারকারীর অ্যাকাউন্ট সমর্থন করে, তাহলে আপনাকে অবশ্যই প্রতিটি টোকেন কোন অ্যাকাউন্টের সাথে যুক্ত তা ট্র্যাক করতে হবে। প্রতিটি OAuth টোকেন সেই ব্যবহারকারীর জন্য নির্দিষ্ট যিনি অ্যাক্সেস অনুমোদিত করেছেন। আপনার অ্যাপ্লিকেশনটি অবশ্যই সঠিক ব্যবহারকারীর সাথে একটি টোকেন সংযুক্ত করতে সক্ষম হবে। এটি পরিচালনা করার একটি উপায় হল টোকেন অনুরোধ করার আগে ব্যবহারকারীকে একটি কুকি ইস্যু করা। ব্যবহারকারী অনুরোধকৃত ডেটাতে অ্যাক্সেস দেওয়ার পরে, Google একটি অনুমোদিত অনুরোধ টোকেন পাঠায় এবং ব্যবহারকারীকে আপনার অ্যাপ্লিকেশনে পুনঃনির্দেশিত করে। তারপরে আপনি সঠিক ব্যবহারকারীর সাথে টোকেনটি সংযুক্ত করতে আপনার অ্যাপ্লিকেশনের কুকি ব্যবহার করতে পারেন।

গুগল পরিষেবা অ্যাক্সেসের অনুরোধ করার জন্য একটি প্রক্রিয়া স্থাপন করা

গুগল পরিষেবার প্রতিটি অনুরোধে স্বাক্ষর থাকতে হবে এবং একটি বৈধ OAuth অ্যাক্সেস টোকেন অন্তর্ভুক্ত থাকতে হবে। সাধারণভাবে, প্রতিটি অনুরোধ HTTP GET অনুরোধের আকারে করা হয়, যার হেডারে অ্যাক্সেস টোকেন এবং স্বাক্ষর অন্তর্ভুক্ত থাকে। নতুন ডেটা লেখার অনুরোধগুলিতে HTTP POST ব্যবহার করা উচিত।

প্রতিটি Google Data API-এর জন্য সঠিক অনুরোধ ফর্ম্যাট সম্পর্কে আরও তথ্যের জন্য, সেই API-এর ডকুমেন্টেশন দেখুন।

OpenID বাস্তবায়ন (ঐচ্ছিক)

যদি আপনি ব্যবহারকারী প্রমাণীকরণের জন্য OpenID প্রয়োগ করেন, তাহলে দুটি প্রক্রিয়া একত্রিত করার জন্য হাইব্রিড প্রোটোকল ব্যবহার করার কথা বিবেচনা করুন। OpenID+OAuth এর মাধ্যমে, একটি অনুরোধ টোকেন পাওয়া এবং এটি অনুমোদন করার কাজগুলি OAuth এক্সটেনশনের সাথে OpenID অনুরোধের অংশ হিসাবে পরিচালিত হয়। OAuthGetRequestToken এর মতো, এই এক্সটেনশনগুলি অ্যাক্সেস করার জন্য Google পরিষেবাগুলি সনাক্ত করতে ব্যবহৃত হয়। OpenID অনুরোধের একটি সফল প্রতিক্রিয়ায় একটি অনুমোদিত অনুরোধ টোকেন থাকে। একবার এই টোকেনটি প্রাপ্ত হয়ে গেলে, অ্যাক্সেস টোকেনের জন্য এটি বিনিময় করতে OAuthGetAccessToken ব্যবহার করুন।

OAuth টোকেন নিয়ে কাজ করা

OAuth ব্যবহার করার জন্য, আপনার অ্যাপ্লিকেশনটিকে নিম্নলিখিত ক্রম অনুসারে সুগঠিত, স্বাক্ষরিত টোকেন অনুরোধ কল তৈরি করতে হবে এবং প্রতিক্রিয়াগুলি পরিচালনা করতে হবে:

  1. একটি অননুমোদিত অনুরোধ টোকেন পান ( OAuthGetRequestToken )
  2. অনুরোধ টোকেনটি অনুমোদন করুন ( OAuthAuthorizeToken )
  3. অনুমোদিত অনুরোধ টোকেনটি একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করুন ( OAuthGetAccessToken )

আপনার আবেদন নিবন্ধিত হোক বা না হোক, সমস্ত OAuth অনুরোধে স্বাক্ষর করতে হবে। আরও তথ্যের জন্য, OAuth অনুরোধে স্বাক্ষর দেখুন।

আপনি OAuth Playground- এ অনুমোদন টোকেন অনুরোধ এবং গ্রহণের সাথে পরীক্ষা করতে পারেন।

বিস্তারিত ডকুমেন্টেশনের জন্য, OAuth API রেফারেন্স দেখুন।

একটি কলব্যাক URL সেট করা হচ্ছে

আপনার অ্যাক্সেস অনুরোধ অনুমোদন করার পর ব্যবহারকারী কোথায় Google তাকে পুনঃনির্দেশিত করবে তা নির্ধারণ করার জন্য, আপনি OAuthGetRequestToken অনুরোধে oauth_callback এর জন্য একটি মান নির্দিষ্ট করতে পারেন। কলব্যাক URL-এ কোয়েরি প্যারামিটার অন্তর্ভুক্ত থাকতে পারে। পুনঃনির্দেশে একই কোয়েরি প্যারামিটার থাকবে, সেইসাথে অনুমোদিত অনুরোধ টোকেনও থাকবে, যা আপনার অ্যাপ্লিকেশনকে পার্স করতে সক্ষম হতে হবে।

উদাহরণস্বরূপ, একাধিক ভাষা সমর্থন করার সময়, আপনি একটি কোয়েরি প্যারামিটার অন্তর্ভুক্ত করতে পারেন যা ব্যবহারকারী যে অ্যাপ্লিকেশনটি দেখছেন তার সংস্করণটি সনাক্ত করে। "http://www.yoursite.com/Retrievetoken?Lang=de" এর একটি oauth_callback মান "http://www.yoursite.com/Retrievetoken?Lang=de&oauth_token=DQAADKEDE" পুনঃনির্দেশিত করবে। টোকেন এবং ভাষা প্যারামিটার পার্স করলে নিশ্চিত হয় যে ব্যবহারকারী সাইটের সঠিক সংস্করণে পুনঃনির্দেশিত হচ্ছে।

যদি oauth_callback প্যারামিটারটি অন্তর্ভুক্ত না করা হয়, তাহলে আপনার অ্যাক্সেস অনুরোধ অনুমোদন করার পরে, Google ব্যবহারকারীকে একটি ওয়েব পৃষ্ঠায় নির্দেশ করবে যেখানে একটি যাচাইকরণ নম্বর প্রদর্শিত হবে ( উদাহরণ দেখুন )। অনুমোদিত অনুরোধ টোকেন পাওয়ার আগে ব্যবহারকারীকে ম্যানুয়ালি আপনার আবেদনে ফিরে যেতে হবে এবং যাচাইকরণ নম্বরটি প্রবেশ করতে হবে।

ব্যবহারকারীদের কাছে আপনার অ্যাপ্লিকেশন সনাক্তকরণ

ব্যবহারকারীর কাছ থেকে অ্যাক্সেস সম্মতির অনুরোধ করার সময় গুগল সাধারণত কোনও অ্যাপ্লিকেশনের নাম প্রদর্শন করে ( উদাহরণ দেখুন )।

যদি আপনার অ্যাপ্লিকেশনটি নিবন্ধিত না থাকে, তাহলে আপনার OAuthGetRequestToken অনুরোধে xoauth_displayname প্যারামিটার ব্যবহার করে আপনার অ্যাপ্লিকেশনের নাম উল্লেখ করুন। যদি সেই প্যারামিটারটি নির্দিষ্ট না থাকে, তাহলে Google oauth_callback প্যারামিটার দ্বারা প্রদত্ত URL এর ডোমেন নাম প্রদর্শন করবে। যদি কোনও কলব্যাক URL প্রদান না করা থাকে, তাহলে Google "anonymous" স্ট্রিংটি প্রদর্শন করবে।

আপনার অ্যাপ্লিকেশনটি নিবন্ধিত থাকলে এই প্যারামিটারটি সেট করবেন না। ডিফল্টরূপে, Google নিবন্ধনের সময় নির্দিষ্ট করা প্রদর্শন নামটি দেখায়। আপনি যদি আপনার OAuthGetRequestToken অনুরোধে একটি প্রদর্শন নাম সেট করেন, তাহলে Google আপনার নিবন্ধিত প্রদর্শন নামের পরিবর্তে এটি ব্যবহার করবে এবং একটি বার্তা অন্তর্ভুক্ত করবে যে আপনার অ্যাপ্লিকেশনের পরিচয় যাচাই করা যাবে না।

দ্রষ্টব্য: OAuth Playground এ xoauth_displayname প্যারামিটার সেট করতে, অনুরোধ টোকেন আনার আগে "Advanced" বক্সটি চেক করুন।

গুগল অ্যাপস ডোমেনের সাথে কাজ করা

যদি আপনার অ্যাপ্লিকেশনটি হোস্ট করা Google অ্যাকাউন্ট ডোমেনের ব্যবহারকারীদের জন্য ডিজাইন করা হয়, তাহলে টোকেন অনুমোদন করার সময় hd প্যারামিটার ব্যবহার করার কথা বিবেচনা করুন। hd প্যারামিটার সম্পর্কে আরও তথ্যের জন্য, একাধিক অ্যাকাউন্ট সহ ব্যবহারকারীদের পরিচালনা দেখুন।

OAuth সম্পর্কে আরও তথ্য

Google-এর OAuth বাস্তবায়ন সম্পর্কে বিস্তারিত তথ্যের জন্য, আপনার আবেদন কীভাবে নিবন্ধন করবেন এবং প্রয়োজনীয় OAuth প্যারামিটারগুলি কীভাবে তৈরি করবেন তা সহ, এই অতিরিক্ত রিসোর্সগুলি দেখুন:

উপরে ফিরে যান

ইনস্টল করা অ্যাপ্লিকেশনগুলির সাথে OAuth ব্যবহার করা

সমস্ত Google ডেটা API OAuth সমর্থন করে, যা অ্যাপ্লিকেশনগুলিতে ডেটা ব্যবহারের অনুমোদনের জন্য একটি উন্মুক্ত মান। ইনস্টল করা অ্যাপ্লিকেশনগুলিকে OAuth ব্যবহার করার জন্য Google-এ নিবন্ধিত হওয়ার প্রয়োজন নেই।

OAuth অনুমোদন প্রক্রিয়া

OAuth অনুমোদন প্রক্রিয়ায় আপনার অ্যাপ্লিকেশন, Google এর অনুমোদন সার্ভার এবং শেষ ব্যবহারকারীর মধ্যে একাধিক মিথস্ক্রিয়া জড়িত।

মৌলিক স্তরে, প্রক্রিয়াটি নিম্নরূপ:

  1. আপনার অ্যাপ্লিকেশনটি অ্যাক্সেসের অনুরোধ করে এবং Google এর অনুমোদন সার্ভার থেকে একটি অননুমোদিত অনুরোধ টোকেন পায়।
  2. গুগল ব্যবহারকারীর কাছে আপনাকে প্রয়োজনীয় ডেটা অ্যাক্সেস দেওয়ার জন্য অনুরোধ করে।
  3. আপনার অ্যাপ্লিকেশনটি অনুমোদন সার্ভার থেকে একটি অনুমোদিত অনুরোধ টোকেন পায়।
  4. আপনি অনুমোদিত অনুরোধ টোকেনটি একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করেন।
  5. আপনি Google এর পরিষেবা অ্যাক্সেস সার্ভার থেকে ডেটা অনুরোধ করতে অ্যাক্সেস টোকেন ব্যবহার করেন।

যখন আপনার অ্যাপ্লিকেশনটি প্রাথমিকভাবে কোনও ব্যবহারকারীর ডেটা অ্যাক্সেসের অনুরোধ করে, তখন Google আপনার অ্যাপ্লিকেশনটিতে একটি অননুমোদিত অনুরোধ টোকেন জারি করে।

যদি ব্যবহারকারী ইতিমধ্যে লগ ইন না করে থাকেন, তাহলে গুগল ব্যবহারকারীকে লগ ইন করতে অনুরোধ করে। এরপর গুগল একটি অনুমোদন পৃষ্ঠা প্রদর্শন করে যা ব্যবহারকারীকে আপনার অ্যাপ্লিকেশন কোন গুগল পরিষেবা ডেটা অ্যাক্সেসের জন্য অনুরোধ করছে তা দেখতে দেয়।

যদি ব্যবহারকারী আপনার অ্যাপ্লিকেশনের অ্যাক্সেস অনুরোধ অনুমোদন করে, তাহলে Google একটি অনুমোদিত অনুরোধ টোকেন জারি করে। প্রতিটি অনুরোধ টোকেন শুধুমাত্র এক ঘন্টার জন্য বৈধ। শুধুমাত্র একটি অনুমোদিত অনুরোধ টোকেন একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করা যেতে পারে এবং এই বিনিময়টি প্রতিটি অনুমোদিত অনুরোধ টোকেনের জন্য শুধুমাত্র একবার করা যেতে পারে।

OAuth আনরেজিস্টারড মোড ব্যবহার করে ইনস্টল করা অ্যাপ্লিকেশনগুলিকে সমর্থন করে। যেহেতু একটি অনুমোদিত অনুরোধ টোকেন পাওয়ার বিভিন্ন পদ্ধতি রয়েছে, তাই আপনার অ্যাপটি যে ডিভাইসে ইনস্টল করা আছে তাতে ওয়েব ব্রাউজার না থাকলেও OAuth ব্যবহার করে একটি অ্যাপ্লিকেশন অনুমোদন করতে পারে।

ডিফল্টরূপে, অ্যাক্সেস টোকেনগুলি দীর্ঘস্থায়ী হয়। প্রতিটি অ্যাক্সেস টোকেন অনুমোদনের জন্য মূল অনুরোধে নির্দিষ্ট ব্যবহারকারীর অ্যাকাউন্টের সাথে নির্দিষ্ট, এবং শুধুমাত্র সেই অনুরোধে নির্দিষ্ট পরিষেবাগুলিতে অ্যাক্সেস মঞ্জুর করে। আপনার অ্যাপ্লিকেশনটিতে অ্যাক্সেস টোকেনটি নিরাপদে সংরক্ষণ করা উচিত, কারণ এটি ব্যবহারকারীর ডেটাতে সমস্ত অ্যাক্সেসের জন্য প্রয়োজনীয়।

OAuth-এর জন্য প্রস্তুতি নেওয়া হচ্ছে

OAuth-এর মাধ্যমে Google অনুমোদন পরিষেবা ব্যবহার করার জন্য আপনার অ্যাপ্লিকেশন সেট আপ করার আগে, আপনাকে নিম্নলিখিত কাজগুলি সম্পন্ন করতে হবে।

আপনার অ্যাপ্লিকেশন কোন ডেটা অ্যাক্সেস করবে তার পরিধি নির্ধারণ করা

প্রতিটি গুগল পরিষেবা গুগল ডেটা এপিআই-এর মাধ্যমে তাদের অ্যাক্সেসের সীমা নির্ধারণ করে। এই অ্যাক্সেসকে স্কোপ মান হিসেবে প্রকাশ করা হয়। কিছু পরিষেবা বিভিন্ন স্কোপ মান প্রদান করে, যার মাধ্যমে ব্যবহারকারীরা কোন অ্যাপ্লিকেশনের কোন ডেটাতে অ্যাক্সেস থাকা উচিত তা বেছে নিতে পারেন। আপনি যে গুগল পরিষেবাটি অ্যাক্সেস করতে চান তার জন্য উপলব্ধ স্কোপ মান সম্পর্কে তথ্যের জন্য, সেই পরিষেবার ডকুমেন্টেশন দেখুন।

সাধারণভাবে, আপনার প্রয়োজনীয় ডেটা সহ সবচেয়ে সংকীর্ণ স্কোপের জন্য একটি টোকেনের অনুরোধ করা উচিত। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশনটির ব্যবহারকারীর "সমস্ত ক্যালেন্ডার" ফিডে অ্যাক্সেসের প্রয়োজন হয়, তাহলে আপনার স্কোপের জন্য একটি টোকেনের অনুরোধ করা উচিত http://www.google.com/calendar/feeds/default/allcalendars/full ।

OAuth টোকেন পরিচালনা করার জন্য একটি প্রক্রিয়া স্থাপন করা হচ্ছে

যখন আপনি কোনও ব্যবহারকারীর ডেটার জন্য OAuth অ্যাক্সেস টোকেন পান, তখন ব্যবহারকারীর পক্ষ থেকে নির্দিষ্ট Google পরিষেবার সাথে ভবিষ্যতের সমস্ত ইন্টারঅ্যাকশনের জন্য আপনাকে সেই অ্যাক্সেস টোকেনটি ব্যবহার করতে হবে।

আপনার অ্যাপ্লিকেশনটি টোকেন স্টোরেজ নিরাপদে পরিচালনা করবে, যার মধ্যে প্রতিটি টোকেন বৈধ এমন Google পরিষেবা ট্র্যাক করাও অন্তর্ভুক্ত।

যদি আপনার অ্যাপ্লিকেশন একাধিক ব্যবহারকারীর অ্যাকাউন্ট সমর্থন করে, তাহলে আপনাকে অবশ্যই প্রতিটি টোকেন কোন অ্যাকাউন্টের সাথে যুক্ত তা ট্র্যাক রাখতে হবে।

গুগল পরিষেবা অ্যাক্সেসের অনুরোধ করার জন্য একটি প্রক্রিয়া স্থাপন করা

গুগল পরিষেবার প্রতিটি অনুরোধে স্বাক্ষর থাকতে হবে এবং একটি বৈধ OAuth অ্যাক্সেস টোকেন অন্তর্ভুক্ত থাকতে হবে। সাধারণভাবে, প্রতিটি অনুরোধ HTTP GET অনুরোধের আকারে করা হয়, যার হেডারে অ্যাক্সেস টোকেন এবং স্বাক্ষর অন্তর্ভুক্ত থাকে। নতুন ডেটা লেখার অনুরোধগুলিতে HTTP POST ব্যবহার করা উচিত।

প্রতিটি Google Data API-এর জন্য সঠিক অনুরোধ ফর্ম্যাট সম্পর্কে আরও তথ্যের জন্য, সেই API-এর ডকুমেন্টেশন দেখুন।

OAuth টোকেন নিয়ে কাজ করা

OAuth ব্যবহার করার জন্য, আপনার অ্যাপ্লিকেশনটিকে নিম্নলিখিত ক্রম অনুসারে সুগঠিত, স্বাক্ষরিত টোকেন অনুরোধ কল তৈরি করতে হবে এবং প্রতিক্রিয়াগুলি পরিচালনা করতে হবে:

  1. একটি অননুমোদিত অনুরোধ টোকেন পান ( OAuthGetRequestToken )
  2. অনুরোধ টোকেনটি অনুমোদন করুন ( OAuthAuthorizeToken )
  3. অনুমোদিত অনুরোধ টোকেনটি একটি অ্যাক্সেস টোকেনের সাথে বিনিময় করুন ( OAuthGetAccessToken )

আপনার আবেদন নিবন্ধিত হোক বা না হোক, সমস্ত OAuth অনুরোধে স্বাক্ষর করতে হবে। আরও তথ্যের জন্য, OAuth অনুরোধে স্বাক্ষর করা দেখুন। ইনস্টল করা অ্যাপ্লিকেশনগুলিকে একটি অনিবন্ধিত অ্যাপ্লিকেশনের জন্য নির্দেশাবলী অনুসরণ করা উচিত।

আপনি OAuth Playground- এ অনুমোদন টোকেন অনুরোধ এবং গ্রহণের সাথে পরীক্ষা করতে পারেন।

বিস্তারিত ডকুমেন্টেশনের জন্য, OAuth API রেফারেন্স দেখুন।

ব্যবহারকারীদের কাছে আপনার অ্যাপ্লিকেশন সনাক্তকরণ

ব্যবহারকারীর কাছ থেকে অ্যাক্সেস সম্মতির অনুরোধ করার সময় গুগল সাধারণত কোনও অ্যাপ্লিকেশনের নাম প্রদর্শন করে ( উদাহরণ দেখুন )।

আপনার অ্যাপ্লিকেশনের নাম নির্দিষ্ট করতে আপনার OAuthGetRequestToken অনুরোধে xoauth_displayname প্যারামিটার ব্যবহার করুন। যদি সেই প্যারামিটারটি নির্দিষ্ট না থাকে, তাহলে Google oauth_callback প্যারামিটার দ্বারা প্রদত্ত URL এর ডোমেন নাম প্রদর্শন করবে। যদি কোনও কলব্যাক URL প্রদান না করা থাকে, তাহলে Google "anonymous" স্ট্রিংটি প্রদর্শন করবে।

দ্রষ্টব্য: OAuth Playground এ xoauth_displayname প্যারামিটার সেট করতে, অনুরোধ টোকেন আনার আগে "Advanced" বক্সটি চেক করুন।

একটি ওয়েব ব্রাউজার চালু করা হচ্ছে

OAuth অনুমোদন প্রক্রিয়ার অংশ হিসেবে, আপনার আবেদনকে অবশ্যই OAuthAuthorizeToken অনুরোধ করতে হবে। এরপর ব্যবহারকারীকে একটি Google ওয়েব পৃষ্ঠায় লগ ইন করতে হবে এবং আপনার আবেদনের অ্যাক্সেস অনুরোধ অনুমোদন করতে হবে।

  • বেশিরভাগ অ্যাপ্লিকেশনের জন্য অটোডিটেক্ট মোড ব্যবহার করা উচিত
  • যেসব অ্যাপ্লিকেশন সম্পূর্ণ ওয়েব ব্রাউজার চালু করতে পারে না, তাদের জন্য ডিভাইস মোড ব্যবহার করা উচিত।
  • ডেভেলপমেন্ট মোড শুধুমাত্র প্রাথমিক ডেভেলপমেন্টের সময় ব্যবহার করা উচিত।

অটোডিটেক্ট মোড

যদি সম্ভব হয়, তাহলে আপনার অ্যাপ্লিকেশনটি একটি ব্রাউজার উইন্ডো চালু করবে এবং Google পৃষ্ঠাটি খোলার জন্য OAuthAuthorizeToken অনুরোধ করবে। যখন Google অনুমোদিত টোকেনটি ফেরত দেবে, তখন আপনার অ্যাপ্লিকেশনটি এটি সনাক্ত করবে এবং ওয়েব ব্রাউজার থেকে ফোকাস ফিরে পাবে।

এই মোডের জন্য আপনাকে একটি কলব্যাক URL প্রদান করতে হবে যেখানে ব্যবহারকারী আপনার অ্যাক্সেস অনুরোধ অনুমোদন করার পরে তাকে পুনঃনির্দেশিত করা হবে। এই URLটি OAuthGetRequestToken অনুরোধের oauth_callback প্যারামিটার এবং OAuthGetAccessToken অনুরোধের verifier প্যারামিটার হিসাবে প্রদান করতে হবে।

ব্যবহারকারীর অভিজ্ঞতা উন্নত করার জন্য, আপনার অ্যাপ্লিকেশনটি স্বয়ংক্রিয়ভাবে সনাক্ত করার চেষ্টা করবে যখন ব্যবহারকারী এই URL-এ পুনঃনির্দেশিত হবে, এবং অবিলম্বে নিজেকে সামনে নিয়ে আসবে এবং OAuth প্রক্রিয়াটি সম্পূর্ণ করার জন্য OAuthGetAccessToken অনুরোধ করবে।

আরও তথ্য এবং সর্বোত্তম অনুশীলনের জন্য, স্বয়ংক্রিয়-সনাক্তকরণ অনুমোদন দেখুন।

যদি আপনার অ্যাপ্লিকেশন স্বয়ংক্রিয়ভাবে সনাক্ত করতে না পারে যে ব্যবহারকারী কখন কলব্যাক URL-এ পুনঃনির্দেশিত হচ্ছে, অথবা নিজেকে ফোরগ্রাউন্ডে আনতে না পারে, তাহলে কলব্যাক URL-এ একটি পৃষ্ঠা প্রদর্শিত হবে যা ব্যাখ্যা করবে কিভাবে আপনার অ্যাপ্লিকেশনকে ফোরগ্রাউন্ডে আনতে হবে এবং কিভাবে আপনার অ্যাপ্লিকেশনের মধ্যে থেকে OAuthGetAccessToken অনুরোধ শুরু করতে হবে।

ডিভাইস মোড

যদি আপনার অ্যাপ্লিকেশনটি একটি সম্পূর্ণ ওয়েব ব্রাউজার চালু করতে না পারে, তাহলে রিচ-ক্লায়েন্ট ডিভাইসগুলির জন্য ওয়েব ব্রাউজার ছাড়াই অনুমোদন করা সম্ভব।

এই মোডটি একজন ডেভেলপারকে এমন একটি ওয়েবসাইট সেট আপ করতে দেয় যেখানে একজন ব্যবহারকারী অ্যাক্সেসের অনুরোধ অনুমোদন করতে পারেন। অনুমোদনের পরে, ব্যবহারকারীকে Google দ্বারা তৈরি একটি কোড দেওয়া হয় এবং ডেভেলপারের সাইটে পুনঃনির্দেশিত করা হয়। এই সাইটটি ব্যবহারকারীকে ব্যাখ্যা করবে কিভাবে অনুমোদন প্রক্রিয়া সম্পন্ন করার জন্য তাদের ডিভাইসে কোডটি ইনপুট করতে হয়।

ডেভেলপমেন্ট মোড

এই মোডটি শুধুমাত্র একটি অ্যাপ্লিকেশনের প্রাথমিক বিকাশের সময় ব্যবহারের জন্য সুপারিশ করা হয়।

AutoDetect মোডের মতো, আপনার অ্যাপ্লিকেশনটিকে একটি ব্রাউজার চালু করতে হবে এবং ব্যবহারকারীকে আপনার অনুরোধ অনুমোদন করতে হবে। তবে, কলব্যাক URL এর জন্য একটি ওয়েবপৃষ্ঠা তৈরি করার পরিবর্তে, আপনি oauth_callback প্যারামিটারের মান "oob" (ব্যান্ডের বাইরে) এ সেট করতে পারেন।

সেক্ষেত্রে, ব্যবহারকারী আপনার অনুরোধ অনুমোদন করার পর, Google ব্যবহারকারীকে একটি Google অ্যাকাউন্ট পৃষ্ঠায় নিয়ে যায় যেখানে একটি যাচাইকরণ নম্বর প্রদর্শিত হয় ( উদাহরণ দেখুন)।

আপনি OAuthGetAccessToken অনুরোধ করার আগে ব্যবহারকারীকে আপনার আবেদনে ফিরে যেতে হবে এবং যাচাইকরণ নম্বরটি প্রবেশ করতে হবে।

OAuth সম্পর্কে আরও তথ্য

Google-এর OAuth বাস্তবায়ন সম্পর্কে বিস্তারিত তথ্যের জন্য, আপনার আবেদন কীভাবে নিবন্ধন করবেন এবং প্রয়োজনীয় OAuth প্যারামিটারগুলি কীভাবে তৈরি করবেন তা সহ, এই অতিরিক্ত রিসোর্সগুলি দেখুন:

উপরে ফিরে যান

অনুমোদনের জন্য AuthSub ব্যবহার করা হচ্ছে

AuthSub হল একটি Google মালিকানাধীন অনুমোদন API, যা বেশিরভাগ Google API-এর জন্য OAuth-এর বিকল্প হিসেবে উপলব্ধ। সম্ভব হলে AuthSub ব্যবহার করা এড়িয়ে চলা উচিত। যদি আপনার ইতিমধ্যেই AuthSub ব্যবহার করে এমন অ্যাপ্লিকেশন থাকে, তাহলে আপনার OAuth অথবা হাইব্রিড প্রোটোকলে স্থানান্তর করা উচিত।

AuthSub অনুমোদন প্রক্রিয়া

AuthSub-এর মাধ্যমে অনুমোদনের ক্ষেত্রে তিনটি সত্তার মধ্যে মিথস্ক্রিয়ার একটি ক্রম জড়িত থাকে: ওয়েব অ্যাপ্লিকেশন, Google পরিষেবা এবং ব্যবহারকারী। এই চিত্রটি ক্রমটি চিত্রিত করে:

অনুমোদন প্রক্রিয়া

  1. যখন ওয়েব অ্যাপ্লিকেশনটির কোনও ব্যবহারকারীর Google পরিষেবা অ্যাক্সেস করার প্রয়োজন হয়, তখন এটি Google এর অনুমোদন প্রক্সি পরিষেবাতে AuthSub কল করে।
  2. অনুমোদন পরিষেবা একটি অ্যাক্সেস অনুরোধ পৃষ্ঠা পরিবেশন করে সাড়া দেয়। এই Google-পরিচালিত পৃষ্ঠাটি ব্যবহারকারীকে তাদের Google পরিষেবাতে অ্যাক্সেস মঞ্জুর/অস্বীকার করতে অনুরোধ করে। ব্যবহারকারীকে প্রথমে তাদের অ্যাকাউন্টে লগ ইন করতে বলা হতে পারে।
  3. ব্যবহারকারী ওয়েব অ্যাপ্লিকেশনে অ্যাক্সেস দেবেন নাকি দেবেন না তা নির্ধারণ করেন। যদি ব্যবহারকারী অ্যাক্সেস অস্বীকার করেন, তাহলে ওয়েব অ্যাপ্লিকেশনে ফিরে যাওয়ার পরিবর্তে তাদের একটি Google পৃষ্ঠায় পাঠানো হবে।
  4. ব্যবহারকারী যদি অ্যাক্সেস মঞ্জুর করেন, তাহলে অনুমোদন পরিষেবা ব্যবহারকারীকে ওয়েব অ্যাপ্লিকেশনে ফিরিয়ে আনবে। পুনর্নির্দেশে একটি অনুমোদন টোকেন থাকে যা একবার ব্যবহারের জন্য উপযুক্ত; এটি একটি দীর্ঘস্থায়ী টোকেনের সাথে বিনিময় করা যেতে পারে।
  5. ওয়েব অ্যাপ্লিকেশনটি ব্যবহারকারীর এজেন্ট হিসেবে কাজ করার জন্য অনুমোদন টোকেন ব্যবহার করে একটি অনুরোধের মাধ্যমে Google পরিষেবার সাথে যোগাযোগ করে।
  6. যদি গুগল পরিষেবা টোকেনটি চিনতে পারে, তাহলে এটি অনুরোধকৃত ডেটা সরবরাহ করে।

AuthSub এর সাথে কাজ করা

আপনার ওয়েব অ্যাপ্লিকেশনে AuthSub অন্তর্ভুক্ত করার জন্য নিম্নলিখিত কাজগুলি প্রয়োজন:

  1. আপনার ওয়েব অ্যাপ্লিকেশনটি নিবন্ধন করবেন কিনা তা সিদ্ধান্ত নিন।

    নিবন্ধিত ওয়েব অ্যাপ্লিকেশনগুলির সুবিধা হল গুগল তাদের স্বীকৃতি দেয়; গুগল লগইন পৃষ্ঠায় ব্যবহারকারীদের কাছে প্রদর্শিত স্ট্যান্ডার্ড সতর্কতা পরিবর্তন করা হয় বা বাদ দেওয়া হয়। এছাড়াও, নিবন্ধিত ওয়েব অ্যাপ্লিকেশনগুলিকে কেবল কলিং URL দিয়ে নয় বরং একটি বর্ণনামূলক নাম দিয়ে চিহ্নিত করা হয়। মনে রাখবেন যে কিছু গুগল পরিষেবা কেবল অনিবন্ধিত ওয়েব অ্যাপ্লিকেশনগুলিতে সীমিত অ্যাক্সেসের অনুমতি দেয়। আপনি যদি নিবন্ধন করতে চান, তাহলে এই স্বয়ংক্রিয় নিবন্ধন প্রক্রিয়াটি ব্যবহার করুন।

    আপনি যদি নিবন্ধন করেন, তাহলে আপনি একটি নিরাপত্তা শংসাপত্র এবং কীও প্রদান করতে পারেন। নিবন্ধিত ওয়েব অ্যাপ্লিকেশনগুলির একটি শংসাপত্র ফাইলে রয়েছে, তারা Google পরিষেবা থেকে ডেটা অনুরোধ করার সময় ব্যবহারের জন্য নিরাপদ টোকেন অর্জন করতে সক্ষম। (প্রয়োজনে তারা অ-সুরক্ষিত টোকেনও ব্যবহার করতে পারে।)

  2. কোন ধরণের টোকেন ব্যবহার করবেন এবং কীভাবে সেগুলি পরিচালনা করবেন তা নির্ধারণ করুন।

    Google থেকে প্রাপ্ত একটি অনুমোদন টোকেন সেই ব্যবহারকারীর জন্য নির্দিষ্ট Google পরিষেবার সাথে ভবিষ্যতের সমস্ত ইন্টারঅ্যাকশনের জন্য ব্যবহার করার উদ্দেশ্যে তৈরি। আপনি যে ধরণের টোকেন ব্যবহার করতে চান - একক-ব্যবহার বা সেশন - তা আপনার ওয়েব অ্যাপ্লিকেশনের Google পরিষেবার সাথে কী ধরণের ইন্টারঅ্যাকশন হবে তার উপর নির্ভর করে। উদাহরণস্বরূপ, যদি ইন্টারঅ্যাকশনটি একবার বা বিরল ঘটনা হয় তবে একটি একক-ব্যবহার টোকেন যথেষ্ট হতে পারে।

    যদি আপনি সেশন টোকেন পেতে চান এবং Google পরিষেবা অ্যাক্সেস করার জন্য নিয়মিত ব্যবহার করেন, তাহলে আপনার ওয়েব অ্যাপ্লিকেশনটিকে টোকেন স্টোরেজ পরিচালনা করতে হবে, যার মধ্যে ব্যবহারকারী এবং টোকেনটি বৈধ Google পরিষেবা ট্র্যাক করা অন্তর্ভুক্ত। Google অ্যাকাউন্টগুলি বিপুল সংখ্যক টোকেন পরিচালনা করার জন্য সেট আপ করা হয়নি এবং প্রকৃতপক্ষে এটি কোনও সময়ে দশটির বেশি বৈধ টোকেন (প্রতি ব্যবহারকারী, প্রতি ওয়েব অ্যাপ্লিকেশন) অসামান্য থাকার অনুমতি দেয় না। এই সীমাবদ্ধতা একটি ওয়েব অ্যাপ্লিকেশনকে প্রয়োজনে বিভিন্ন পরিষেবা কভার করার জন্য একাধিক টোকেন পেতে দেয়; এটি ওয়েব অ্যাপ্লিকেশনের প্রতিবার Google পরিষেবা অ্যাক্সেস করার সময় একটি নতুন টোকেন পাওয়ার সমর্থন করে না। আপনি যদি সেশন টোকেন সংরক্ষণ করার সিদ্ধান্ত নেন, তাহলে টোকেনগুলিকে সার্ভারে সংরক্ষিত অন্যান্য সংবেদনশীল তথ্যের মতোই নিরাপদে বিবেচনা করা উচিত।

    বিকল্পভাবে, আপনি যদি একটি টোকেন প্রত্যাহার প্রক্রিয়া সেট আপ করেন তবে আপনি নিয়মিতভাবে নতুন টোকেন পেতে পারেন। আপনার আবেদনের জন্য অন্য একটি অনুরোধ করার আগে বিদ্যমান টোকেনটি প্রত্যাহার করতে হবে। এই পরিস্থিতিতে, ব্যবহারকারীকে প্রতিবার নতুন টোকেনের অনুরোধ করা হলে লগ ইন করতে হবে এবং অ্যাক্সেস দিতে হবে।

  3. গুগল পরিষেবাটি অ্যাক্সেস করার জন্য প্রয়োজনীয় সুযোগ নির্ধারণ করুন।

    প্রতিটি গুগল পরিষেবা নির্ধারণ করে যে এটি কতটা এবং কী ধরণের অ্যাক্সেসের অনুমতি দেবে। এই অ্যাক্সেসকে একটি স্কোপ মান হিসাবে প্রকাশ করা হয়। একটি পরিষেবার স্কোপ একটি সাধারণ URL হতে পারে যা সম্পূর্ণ পরিষেবা সনাক্ত করে, অথবা এটি আরও সীমাবদ্ধ অ্যাক্সেস নির্দিষ্ট করতে পারে। কিছু পরিষেবা অ্যাক্সেসকে কঠোরভাবে সীমাবদ্ধ করে, যেমন সীমিত তথ্যে কেবল-পঠনযোগ্য অ্যাক্সেসের অনুমতি দেওয়া। আপনি যে গুগল পরিষেবাটি অ্যাক্সেস করতে চান তার জন্য অনুমোদিত স্কোপগুলি পেতে, সেই পরিষেবার ডকুমেন্টেশনটি দেখুন। আপনার সম্ভাব্য সবচেয়ে শক্তভাবে স্কোপযুক্ত টোকেনটি অনুরোধ করা উচিত। উদাহরণস্বরূপ, যদি আপনি Gmail এর অ্যাটম ফিড বৈশিষ্ট্যটি অ্যাক্সেস করার চেষ্টা করেন, তাহলে "http://www.google.com/calendar/" নয়, "http://www.google.com/calendar/" স্কোপটি ব্যবহার করুন। বৃহৎ-স্কোপ অনুরোধের ক্ষেত্রে গুগল পরিষেবাগুলি অনেক বেশি সীমাবদ্ধ।

  4. অনুমোদন টোকেনের অনুরোধ এবং গ্রহণের জন্য একটি ব্যবস্থা স্থাপন করুন।

    এই প্রক্রিয়াটি অবশ্যই একটি সুগঠিত AuthSubRequest কল তৈরি করবে, যার মধ্যে উপযুক্ত পরবর্তী এবং স্কোপ URL মানগুলি নির্দিষ্ট করা থাকবে (ধাপ 3 এ নির্ধারিত)। আপনি যদি সুরক্ষিত টোকেন ব্যবহার করেন এবং/অথবা সেশন টোকেন পরিচালনা করেন, তাহলে অনুরোধে এই ভেরিয়েবলগুলির জন্য মানগুলিও অন্তর্ভুক্ত থাকতে হবে।

    পরবর্তী URL-এ কোয়েরি প্যারামিটার অন্তর্ভুক্ত থাকতে পারে। উদাহরণস্বরূপ, একাধিক ভাষা সমর্থন করার সময়, একটি কোয়েরি প্যারামিটার অন্তর্ভুক্ত করুন যা ব্যবহারকারী যে ওয়েব অ্যাপ্লিকেশনটি দেখছেন তার সংস্করণটি সনাক্ত করে। http://www.yoursite.com/Retrievetoken?Lang=de এর পরবর্তী মানটি http://www.yoursite.com/Retrievetoken?Lang=de&token=DQAADKEDE পুনঃনির্দেশিত করবে। টোকেন এবং ল্যাং প্যারামিটার পার্সিং নিশ্চিত করে যে ব্যবহারকারীকে সাইটের সঠিক সংস্করণে পুনঃনির্দেশিত করা হয়েছে।

    কিছু পরিস্থিতিতে, hd প্যারামিটার ব্যবহার করলে আপনার ব্যবহারকারীদের Google অ্যাকাউন্ট সাইটে অ্যাক্সেস দেওয়ার সময় তাদের অভিজ্ঞতা সহজতর হতে পারে। বেশিরভাগ ক্ষেত্রে, প্রক্রিয়াটি তাদের অ্যাকাউন্টে লগ ইন করা এবং অ্যাক্সেস দেওয়ার সিদ্ধান্ত নেওয়া সহজ। তবে, যাদের একাধিক Google অ্যাকাউন্ট (একটি নিয়মিত জিমেইল অ্যাকাউন্ট এবং/অথবা এক বা একাধিক Google অ্যাপস হোস্টেড অ্যাকাউন্ট ) আছে, তাদের কোন অ্যাকাউন্টটি অ্যাক্সেস করতে চান তা সনাক্ত করার জন্য অতিরিক্ত "ইউনিভার্সাল লগইন" প্রক্রিয়া অনুসরণ করতে হতে পারে। যদি আপনার অ্যাপ্লিকেশনটি একটি নির্দিষ্ট পরিচালিত ডোমেনের জন্য ডিজাইন করা হয়, তাহলে আপনি সেই ডোমেনটি সনাক্ত করতে এই প্যারামিটার ব্যবহার করে এই অতিরিক্ত পদক্ষেপগুলি বাদ দিতে পারেন। আপনার অ্যাপ্লিকেশনটি যদি এমন পরিষেবাগুলি অ্যাক্সেস করে যা হোস্টেড অ্যাকাউন্টগুলিতে উপলব্ধ নয় - তাহলে আপনি hd প্যারামিটারটিও ব্যবহার করতে পারেন - মান 'ডিফল্ট' সেট করলে অনুমোদন কেবল নিয়মিত অ্যাকাউন্টের মধ্যে সীমাবদ্ধ থাকবে। যখন hd মান সেট করা হয়, তখন Google স্বয়ংক্রিয়ভাবে অনুমোদনের জন্য সঠিক অ্যাকাউন্টটি নির্বাচন করবে।

    টোকেন মেকানিজমটি এমনভাবে সজ্জিত থাকতে হবে যাতে গুগল থেকে প্রাপ্ত রিডাইরেক্ট পার্স করা যায়, যেখানে সিঙ্গেল-ইউজ টোকেন থাকে, এবং এর সাথে ব্যবস্থা নেওয়া যায়। যেহেতু অনুমোদন টোকেনগুলি একজন ব্যবহারকারীর জন্য নির্দিষ্ট, তাই আপনার অ্যাপ্লিকেশনটিকে অবশ্যই তার ব্যবহারকারীর সাথে একটি টোকেন সংযুক্ত করতে সক্ষম হতে হবে। টোকেন অনুরোধ করার আগে ব্যবহারকারীকে একটি কুকি ইস্যু করা পছন্দের বিকল্প। তারপর, যখন গুগল একটি সংযুক্ত টোকেন ব্যবহার করে ব্যবহারকারীকে আপনার সাইটে ফিরিয়ে আনে, তখন আপনার অ্যাপ্লিকেশন কুকিটি পড়তে পারে এবং টোকেনটিকে সঠিক ব্যবহারকারী সনাক্তকরণের সাথে সংযুক্ত করতে পারে।

  5. সেশন টোকেন অনুরোধ করার জন্য ব্যবস্থা স্থাপন করুন এবং প্রাসঙ্গিক হলে সেগুলি সংরক্ষণ বা প্রত্যাহার করুন।

    ধাপ ২-এ আপনি কোন টোকেন পরিচালনার সিদ্ধান্ত নিয়েছেন তার উপর নির্ভর করে, আপনাকে সেশন টোকেনগুলি পেতে এবং প্রত্যাহার করার জন্য একটি প্রক্রিয়া তৈরি করতে হতে পারে ( AuthSubSessionToken এবং AuthSubRevokeToken )। সেশন এবং প্রত্যাহার প্রক্রিয়া পরীক্ষা করার জন্য, AuthSubTokenInfo ব্যবহার করুন, যা নির্দেশ করে যে প্রদত্ত টোকেনটি বৈধ কিনা। টোকেন সংরক্ষণ করলে, অ্যাপ্লিকেশনটিকে অবশ্যই ব্যবহারকারী আইডি এবং টোকেনের আওতাভুক্ত পরিষেবা (স্কোপ) উভয়ই ট্র্যাক করতে হবে।

  6. গুগল পরিষেবা অ্যাক্সেসের অনুরোধ করার জন্য একটি প্রক্রিয়া সেট আপ করুন।

    সঠিক অনুরোধ ফর্ম্যাট সম্পর্কে তথ্যের জন্য Google পরিষেবার ডকুমেন্টেশন দেখুন। Google পরিষেবার সমস্ত অনুরোধে একটি বৈধ অনুমোদন টোকেন অন্তর্ভুক্ত থাকতে হবে। সাধারণভাবে, Google পরিষেবার কাছে একটি অনুরোধ একটি HTTP GET (অথবা নতুন ডেটা লেখার সময় POST) আকারে হয়, যার টোকেনটি অনুরোধ শিরোনামে উল্লেখ করা থাকে।

    অনুরোধের শিরোনামটি নিম্নলিখিত ফর্মটি গ্রহণ করা উচিত:

    Authorization: AuthSub token="token"

    যেখানে টোকেন হল অনুমোদন টোকেন, একক-ব্যবহার বা সেশন, যা AuthSub অনুরোধের প্রতিক্রিয়ায় Google থেকে প্রাপ্ত। যদি টোকেনটি সুরক্ষিত থাকে, তাহলে এটির সাথে একটি ডিজিটাল স্বাক্ষর থাকতে হবে। নির্দেশাবলী এবং উদাহরণের জন্য " স্বাক্ষর অনুরোধ " দেখুন।

    The example below illustrates a request header for a call to the Google Calendar feed service. This request contains a non-secure token:

    GET /calendar/feeds/default/private/full HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: AuthSub token="GD32CMCL25aZ-v____8B"
User-Agent: Java/1.5.0_06
Host: www.google.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

More information about AuthSub

For information on AuthSub, including registering your application with Google and a detailed explanation of exchanging a one-time token for a session token, see these additional resources:

উপরে ফিরে যান

Using ClientLogin for authorization

ClientLogin is a Google proprietary authorization API, available as an alternative to OAuth for most Google APIs. You should avoid using ClientLogin if possible. If you already have applications that use ClientLogin, you should migrate to OAuth or the hybrid protocol.

Authentication for Installed Applications: ClientLogin

ClientLogin allows your users to log into their Google account from inside your application. The application then contacts Google with the login data and requests access to a specified Google Data API. Once the login information has been successfully authenticated, Google returns a token, which your application will reference each time it requests access to the user's account, such as to get or post data. The token remains valid for a set length of time, defined by whichever Google service you're working with.

Note : The Google Data APIs Client Libraries provide methods to help you use ClientLogin in your installed applications. Specifically, there are methods for acquiring an authentication token, handling CAPTCHA challenges, recalling the auth token for later use, and sending the correct Authorization header with every request. If you are working with one of the libraries, see Using ClientLogin with the Google Data APIs Client Libraries .

The ClientLogin authorization process

Authorization with ClientLogin involves a sequence of interactions between three entities: the installed application, Google services, and the user. This diagram illustrates the sequence:

Authorization process

  1. When the third-party application needs to access a user's Google service, it retrieves the user's login name and password.
  2. The third-party application then makes a ClientLogin call to Google's Authorization service.
  3. If the Google Authorization service decides additional vetting is necessary, it returns failure response with a CAPTCHA token and challenge, in the form of a URL for a CAPTCHA image.
  4. If a CAPTCHA challenge is received, the third-party application displays the CAPTCHA image for the user and solicits an answer from the user.
  5. If requested, the user submits an answer to the CAPTCHA challenge.
  6. The third-party application makes a new ClientLogin call, this time including the CAPTCHA answer and token (received with the failure response).
  7. On a successful login attempt (with or without CAPTCHA challenge), the Google Authorization service returns a token to the application.
  8. The application contacts the Google service with a request for data access, referencing the token received from the Google Authorization service.
  9. If the Google service recognizes the token, it supplies the requested data access.

Using ClientLogin

Use this interface in your installed application to programmatically access a user's Google account. After collecting login information from the user, call ClientLogin to request access to the user's account. Once the login information has been successfully authenticated, Google returns a token, which your application will reference each time it requests access to the user's account. The token remains valid for a set length of time, which is defined by whichever Google service you're working with.

Incorporating ClientLogin into your application requires these tasks:

  1. Create a UI element to capture login data from the user.

    The UI needs to solicit a user name (email address including domain) and password. The UI should also be capable of displaying a CAPTCHA image using the URL received from Google, if one is required, and soliciting a correct answer from the user. Ideally, your UI will include a link to Google Accounts login page ("https://www.google.com/accounts/Login") in the event that the user needs to sign up for a new account or do other account maintenance.

  2. Write code to generate a well-formed HTTPS POST ClientLogin request and transmit it.

    This code needs to contain logic to handle a CAPTCHA challenge and include both the logintoken and logincaptcha parameters. The application should also be able to detect when the user omits required information--or repeats incorrect data after a login failure--and display an error without sending a superfluous request.

  3. Handle responses from Google.

    There are four possible responses to a login request:

    • success (an HTTP 200)
    • failure (an HTTP 403) with an explanatory error code
    • invalid request, generally resulting from a malformed request
    • failure with a CAPTCHA challenge

    A success response contains an authorization token labeled "Auth". This token must be included in all subsequent requests to the Google service for this account. Authorization tokens should be closely guarded and should not be given to any other application, as they represent access to the user's account. The time limit on the token varies depending on which service issued it.

    A failure response includes one or more error codes and a URL with the error message that can be displayed for the user. Please note that ClientLogin does not differentiate between a failure due to an incorrect password or one due to an unrecognized user name (for example, if the user has not yet signed up for an account). Your application needs to handle all possible error messages as appropriate.

    A failure response with a CAPTCHA challenge means that Google has decided, for whatever reason, that additional security measures should be taken. This response is accompanied by a CAPTCHA image URL and a token representing the specific CAPTCHA challenge.

  4. Handle a CAPTCHA challenge from Google.

    To handle the challenge, the application must display the CAPTCHA image and solicit an answer from the user. To display the CAPTCHA image, use the value of CaptchaUrl returned with the failure response, prefixing it with the Google Accounts URL: "http://www.google.com/accounts/". Once the user provides an answer, the application should resend the login request, this time including the CAPTCHA token ( logintoken ) and the user's answer ( logincaptcha ). Google validates the user's answer before authorizing access to the account.

    There is an alternative for developers who do not want to manage the process's of getting and transmitting a user CAPTCHA response. In response to a CAPTCHA challenge, the application can direct the user to the Google hosted page: "https://www.google.com/accounts/DisplayUnlockCaptcha". Once the user has successfully responded to the challenge, the Google server trusts the computer in use. The application can then resend the original login request to obtain the authorization token.

    5. Note: Google does not validate the login attempt prior to issuing a CAPTCHA challenge. This means a login attempt could fail even after a CAPTCHA challenge.

* CAPTCHA is a trademark of Carnegie Mellon University

উপরে ফিরে যান

Authentication for Gadgets

OAuth Proxy

If you're building a gadget using the standard Gadgets API , you can leverage a feature of the gadget platform called the OAuth Proxy to access the Google Data APIs. OAuth ( described above ) is an authentication standard that allows users to access their private data in a gadget hosting service such as iGoogle, MySpace, or Orkut, or share their data with another website or gadget. The OAuth Proxy is designed to make development easier for gadget developers by hiding many of OAuth's authentication details. The Proxy is based on an open-source project called Shindig , which is an implementation of the gadget specification.

Note : The OAuth Proxy is only supported for gadgets that use the gadgets.* API and run in OpenSocial containers. It is not supported for the legacy gadgets API .

Authentication flow

Your gadget must obtain an OAuth token before it can access a user's data. The OAuth Proxy manages the authentication flow for you. The first time a user installs your gadget, the following process takes place:

  1. Your gadget loads for the first time and attempts to access the user's data using one of the Google Data APIs.
  2. The request fails because the user hasn't granted access. The response object contains a URL (in response.oauthApprovalUrl ) for the OAuth approval page. Your gadget should provide a method to launch a new window with that URL.
  3. On the approval page, the user chooses to grant or deny access to your gadget. If successful, the user is taken to the oauth_callback page you specify. For the best user experience, use http://oauth.gmodules.com/gadgets/oauthcallback .
  4. Next, the user closes the popup window. To notify your gadget that the user has approved, you can use a popup handler to detect the approval window closing. Alternatively, your gadget can display a link (eg " I've approved access ") for the user to click after this window closes.
  5. Your gadget attempts to access the Google Data API a second time by re-requesting the user's data. This attempt is successful.
  6. Your gadget is authenticated and can begin operating normally.

Gadget setup

To access one or more of the Google Data APIs, you first need to tell your gadget to use OAuth as the authentication method. Add an <OAuth> element in the <ModulePrefs> section of your gadget's XML:

<ModulePrefs>
...
<OAuth>
  <Service name="google">
    <Access url="https://www.google.com/accounts/OAuthGetAccessToken" method="GET" />
    <Request url="https://www.google.com/accounts/OAuthGetRequestToken?
                  scope=http://www.blogger.com/feeds/%20http://www.google.com/calendar/feeds/" method="GET" />
    <Authorization url="https://www.google.com/accounts/OAuthAuthorizeToken?
                        oauth_callback=http://oauth.gmodules.com/gadgets/oauthcallback" />
  </Service>
</OAuth>
...
</ModulePrefs>

In this section, only change the following query parameters:

scope
A required parameter in the Request URL. Your gadget can access data from the scope (s) used in this parameter. In this example, the gadget can access Blogger and Calendar data. A gadget can request data for a single scope or multiple scopes, as this example does.
oauth_callback
An optional parameter in the Authorization URL. The OAuth approval page redirects to this URL after the user has approved access to data. You should set this parameter to http://oauth.gmodules.com/gadgets/oauthcallback to provide the best user experience when users install your gadget. That page provides a snippet of JavaScript that automatically closes the popup window. Alternatively, you can set this parameter to point to your own "approved" page, or you can simply leave the parameter blank.

Accessing an authenticated Google Data API feed

Once your gadget has authenticated the user, accessing a Google Data API is straightforward with the Google Data APIs JavaScript client library. For information on how to use the library in the OAuth Proxy, see Using the JavaScript Client Library .

More information about Gadgets

For complete information on creating Google Data API Gadgets, including details on the OAuth Proxy, an article on how to get started, and the gadgets.* spec, see these additional resources:

উপরে ফিরে যান