Wear OS অ্যাপগুলি কোনও সহযোগী অ্যাপ ছাড়াই স্বতন্ত্রভাবে চলতে পারে। এর অর্থ হল ইন্টারনেট থেকে ডেটা অ্যাক্সেস করার সময় একটি Wear OS অ্যাপকে নিজেরাই প্রমাণীকরণ পরিচালনা করতে হবে। কিন্তু ঘড়ির ছোট স্ক্রিনের আকার এবং হ্রাসপ্রাপ্ত ইনপুট ক্ষমতা একটি Wear OS অ্যাপের ব্যবহারযোগ্য প্রমাণীকরণ বিকল্পগুলিকে সীমিত করে।
এই নির্দেশিকাটি Wear OS অ্যাপ, ক্রেডেনশিয়াল ম্যানেজারের জন্য প্রস্তাবিত প্রমাণীকরণ পদ্ধতির দিকনির্দেশনা প্রদান করে।
একটি ভালো সাইন-ইন অভিজ্ঞতা কীভাবে ডিজাইন করবেন সে সম্পর্কে আরও জানতে, সাইন-ইন UX নির্দেশিকাটি দেখুন।
প্রাথমিক বিবেচনা
আপনার বাস্তবায়ন শুরু করার আগে, নিম্নলিখিত বিষয়গুলি বিবেচনা করুন।
অতিথি মোড
সমস্ত কার্যকারিতার জন্য প্রমাণীকরণের প্রয়োজন নেই। পরিবর্তে, ব্যবহারকারীকে সাইন ইন করার প্রয়োজন ছাড়াই যতটা সম্ভব বৈশিষ্ট্য সরবরাহ করুন।
ব্যবহারকারীরা মোবাইল অ্যাপ ব্যবহার না করেই আপনার Wear অ্যাপটি আবিষ্কার এবং ইনস্টল করতে পারেন, যার ফলে তাদের অ্যাকাউন্ট নাও থাকতে পারে এবং এটি কোন বৈশিষ্ট্যগুলি অফার করে তাও নাও জানতে পারে। নিশ্চিত করুন যে গেস্ট মোড কার্যকারিতাটি আপনার অ্যাপের বৈশিষ্ট্যগুলি সঠিকভাবে প্রদর্শন করে।
কিছু ডিভাইস বেশিক্ষণ আনলক থাকতে পারে
Wear OS 5 বা তার উচ্চতর ভার্সন চালিত সমর্থিত ডিভাইসগুলিতে, সিস্টেমটি ব্যবহারকারীর কব্জিতে ডিভাইসটি পরে আছে কিনা তা সনাক্ত করে। ব্যবহারকারী যদি কব্জি সনাক্তকরণ বন্ধ করে এবং তারপর তার কব্জি থেকে ডিভাইসটি খুলে ফেলে, তাহলে সিস্টেমটি অন্য সময়ের তুলনায় ডিভাইসটিকে দীর্ঘ সময়ের জন্য আনলক রাখে।
যদি আপনার অ্যাপের উচ্চ স্তরের নিরাপত্তার প্রয়োজন হয়—যেমন সম্ভাব্য সংবেদনশীল বা ব্যক্তিগত ডেটা প্রদর্শনের সময়—প্রথমে কব্জি সনাক্তকরণ সক্ষম কিনা তা পরীক্ষা করুন:
val wristDetectionEnabled =
isWristDetectionAutoLockingEnabled(applicationContext)
যদি এই পদ্ধতির রিটার্ন মান false হয়, তাহলে ব্যবহারকারী-নির্দিষ্ট সামগ্রী প্রদর্শনের আগে ব্যবহারকারীকে আপনার অ্যাপে একটি অ্যাকাউন্টে সাইন ইন করতে অনুরোধ করুন।
শংসাপত্র ব্যবস্থাপক
Wear OS-এ প্রমাণীকরণের জন্য ক্রেডেনশিয়াল ম্যানেজার হল প্রস্তাবিত API। এটি ব্যবহারকারীদের একটি স্বতন্ত্র সেটিংসে Wear OS অ্যাপ্লিকেশনগুলিতে সাইন ইন করার জন্য আরও নিরাপদ পরিবেশ প্রদান করে, কোনও সংযুক্ত ফোনের প্রয়োজন ছাড়াই এবং তাদের পাসওয়ার্ড মনে রাখার প্রয়োজন ছাড়াই।
এই ডকুমেন্টটি ডেভেলপারদের দ্বারা হোস্ট করা স্ট্যান্ডার্ড প্রমাণীকরণ প্রক্রিয়াগুলির সাথে একটি ক্রেডেনশিয়াল ম্যানেজার সমাধান বাস্তবায়নের জন্য প্রয়োজনীয় তথ্যের রূপরেখা দেয়, যা হল:
- পাসকি
- পাসওয়ার্ড
- ফেডারেটেড আইডেন্টিটি (যেমন গুগল দিয়ে সাইন ইন করুন)
এই নির্দেশিকাটি ক্রেডেনশিয়াল ম্যানেজারের জন্য ব্যাকআপ হিসেবে অন্যান্য গ্রহণযোগ্য Wear OS প্রমাণীকরণ পদ্ধতি ( ডেটা লেয়ার টোকেন শেয়ারিং এবং OAuth ) কীভাবে স্থানান্তরিত করতে হয় তার নির্দেশিকা এবং বর্তমানে বন্ধ হয়ে যাওয়া স্বতন্ত্র Google সাইন ইন বোতাম থেকে এমবেডেড ক্রেডেনশিয়াল ম্যানেজার সংস্করণে রূপান্তর পরিচালনা করার জন্য বিশেষ নির্দেশিকা প্রদান করে।
Wear OS এর সীমাবদ্ধতা এবং পার্থক্য
ডেভেলপারদের Wear OS-এর নিম্নলিখিত সীমাবদ্ধতা এবং পার্থক্যগুলি সম্পর্কে সচেতন থাকা উচিত:
- ক্রেডেনশিয়াল ম্যানেজার শুধুমাত্র Wear OS 4 এবং তার পরবর্তী সংস্করণে উপলব্ধ।
- Wear OS-এ শংসাপত্র তৈরি করা যাবে না
- "পুনরুদ্ধার শংসাপত্র" বা হাইব্রিড সাইন-ইন প্রবাহ উভয়ই সমর্থিত নয়।
- শুধুমাত্র Wear OS ইন্টিগ্রেশন সহ ক্রেডেনশিয়াল প্রোভাইডারগুলি মোবাইল থেকে পুনরায় ব্যবহার করা যেতে পারে।
Wear OS-এ পাসকি
ডেভেলপারদের তাদের Wear OS ক্রেডেনশিয়াল ম্যানেজার বাস্তবায়নে পাসকি প্রয়োগ করার জন্য জোরালোভাবে উৎসাহিত করা হচ্ছে। পাসকি হল শেষ-ব্যবহারকারী প্রমাণীকরণের জন্য নতুন শিল্প মান, এবং এগুলি ব্যবহারকারীদের জন্য বেশ কিছু উল্লেখযোগ্য সুবিধা বহন করে।
পাসকিগুলি আরও সহজ
- ব্যবহারকারীরা সাইন ইন করার জন্য একটি অ্যাকাউন্ট নির্বাচন করতে পারেন। তাদের ব্যবহারকারীর নাম টাইপ করার প্রয়োজন নেই।
- ব্যবহারকারীরা ডিভাইসের স্ক্রিন লক ব্যবহার করে প্রমাণীকরণ করতে পারবেন।
- একটি পাসকি তৈরি এবং নিবন্ধিত হওয়ার পরে, ব্যবহারকারী নির্বিঘ্নে একটি নতুন ডিভাইসে স্যুইচ করতে পারবেন এবং পুনরায় নিবন্ধনের প্রয়োজন ছাড়াই তাৎক্ষণিকভাবে এটি ব্যবহার করতে পারবেন।
পাসকিগুলি নিরাপদ
- ডেভেলপাররা পাসওয়ার্ড সংরক্ষণের পরিবর্তে কেবল একটি পাবলিক কী সার্ভারে সংরক্ষণ করে, যার অর্থ হল কোনও খারাপ ব্যক্তি সার্ভার হ্যাক করার জন্য অনেক কম মূল্য পায় এবং লঙ্ঘনের ক্ষেত্রে পরিষ্কার করার কাজও অনেক কম হয়।
- পাসকি ফিশিং-প্রতিরোধী সুরক্ষা প্রদান করে। পাসকি শুধুমাত্র তাদের নিবন্ধিত ওয়েবসাইট এবং অ্যাপগুলিতে কাজ করে; কোনও ব্যবহারকারীকে প্রতারণামূলক সাইটে প্রমাণীকরণের জন্য প্রতারিত করা যাবে না কারণ ব্রাউজার বা অপারেটিং সিস্টেম যাচাইকরণ পরিচালনা করে।
- পাসকি এসএমএস পাঠানোর প্রয়োজনীয়তা কমিয়ে দেয়, যা প্রমাণীকরণকে আরও সাশ্রয়ী করে তোলে।
পাসকি বাস্তবায়ন করুন
সকল ধরণের বাস্তবায়নের জন্য সেটআপ এবং নির্দেশিকা অন্তর্ভুক্ত।
সেটআপ
আপনার অ্যাপ্লিকেশন মডিউলের build.gradle ফাইলে লক্ষ্য API স্তর 35 এ সেট করুন:
android { defaultConfig { targetSdkVersion(35) } }androidx.credentialsরিলিজ রেফারেন্সের সর্বশেষ স্থিতিশীল সংস্করণ ব্যবহার করে আপনার অ্যাপ বা মডিউলের build.gradle ফাইলে নিম্নলিখিত লাইনগুলি যোগ করুন।androidx.credentials:credentials:1.5.0 androidx.credentials:credentials-play-services-auth:1.5.0
অন্তর্নির্মিত প্রমাণীকরণ পদ্ধতি
যেহেতু ক্রেডেনশিয়াল ম্যানেজার একটি ইউনিফাইড এপিআই, তাই ওয়্যার ওএসের বাস্তবায়নের ধাপগুলি অন্য যেকোনো ডিভাইসের মতোই।
শুরু করতে এবং পাসকি এবং পাসওয়ার্ড সমর্থন বাস্তবায়ন করতে মোবাইল নির্দেশাবলী ব্যবহার করুন।
ক্রেডেনশিয়াল ম্যানেজারে "সাইন ইন উইথ গুগল" সাপোর্ট যোগ করার ধাপগুলি মোবাইল ডেভেলপমেন্টের জন্য তৈরি, কিন্তু Wear OS-এর ক্ষেত্রেও ধাপগুলি একই রকম। এই ক্ষেত্রে বিশেষ বিবেচনার জন্য "লিগ্যাসি সাইন ইন উইথ গুগল থেকে স্থানান্তর" বিভাগটি দেখুন।
মনে রাখবেন যেহেতু Wear OS-এ শংসাপত্র তৈরি করা যায় না, তাই আপনাকে মোবাইল নির্দেশাবলীতে উল্লিখিত শংসাপত্র তৈরির পদ্ধতিগুলি বাস্তবায়ন করার প্রয়োজন নেই।
ব্যাকআপ প্রমাণীকরণ পদ্ধতি
Wear OS অ্যাপের জন্য আরও দুটি গ্রহণযোগ্য প্রমাণীকরণ পদ্ধতি রয়েছে: OAuth 2.0 (উভয় রূপ), এবং মোবাইল অথ টোকেন ডেটা লেয়ার শেয়ারিং। যদিও এই পদ্ধতিগুলির ক্রেডেনশিয়াল ম্যানেজার API-তে ইন্টিগ্রেশন পয়েন্ট নেই, ব্যবহারকারীরা ক্রেডেনশিয়াল ম্যানেজার স্ক্রিনটি বাতিল করে দিলে ফলব্যাক হিসাবে এগুলি আপনার ক্রেডেনশিয়াল ম্যানেজারের UX প্রবাহে অন্তর্ভুক্ত করা যেতে পারে।
ক্রেডেনশিয়াল ম্যানেজার স্ক্রিনটি খারিজ করার ব্যবহারকারীর ক্রিয়া পরিচালনা করতে, আপনার GetCredential লজিকের অংশ হিসাবে একটি NoCredentialException ধরুন এবং আপনার নিজস্ব কাস্টম auth UI এ নেভিগেট করুন।
yourCoroutineScope.launch {
try {
val response = credentialManager.getCredential(activity, request)
signInWithCredential(response.credential)
} catch (e: GetCredentialCancellationException) {
navigateToFallbackAuthMethods()
}
}
আপনার কাস্টম প্রমাণীকরণ UI এরপর সাইন-ইন UX নির্দেশিকায় বর্ণিত অন্য যেকোনো গ্রহণযোগ্য প্রমাণীকরণ পদ্ধতি প্রদান করতে পারে।
ডেটা লেয়ার টোকেন শেয়ারিং
ফোন কম্প্যানিয়ন অ্যাপটি Wearable Data Layer API ব্যবহার করে Wear OS অ্যাপে নিরাপদে প্রমাণীকরণ ডেটা স্থানান্তর করতে পারে। বার্তা বা ডেটা আইটেম হিসাবে শংসাপত্র স্থানান্তর করুন।
এই ধরণের প্রমাণীকরণের জন্য সাধারণত ব্যবহারকারীর কাছ থেকে কোনও পদক্ষেপ নেওয়ার প্রয়োজন হয় না। তবে, ব্যবহারকারীকে সাইন ইন করার বিষয়টি না জানিয়ে প্রমাণীকরণ করা এড়িয়ে চলুন। আপনি একটি খারিজযোগ্য স্ক্রিন ব্যবহার করে ব্যবহারকারীকে জানাতে পারেন যা দেখায় যে তাদের অ্যাকাউন্ট মোবাইল থেকে স্থানান্তরিত হচ্ছে।
গুরুত্বপূর্ণ: আপনার Wear OS অ্যাপে কমপক্ষে আরেকটি প্রমাণীকরণ পদ্ধতি অফার করতে হবে, কারণ এই বিকল্পটি শুধুমাত্র Android-পেয়ার করা ঘড়িতে কাজ করে যখন সংশ্লিষ্ট মোবাইল অ্যাপটি ইনস্টল করা থাকে। যেসব ব্যবহারকারীর কাছে সংশ্লিষ্ট মোবাইল অ্যাপ নেই অথবা যাদের Wear OS ডিভাইসটি iOS ডিভাইসের সাথে যুক্ত তাদের জন্য একটি বিকল্প প্রমাণীকরণ পদ্ধতি প্রদান করুন।
মোবাইল অ্যাপ থেকে ডেটা লেয়ার ব্যবহার করে টোকেন পাস করুন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:
val token = "..." // Auth token to transmit to the Wear OS device.
val dataClient: DataClient = Wearable.getDataClient(context)
val putDataReq: PutDataRequest = PutDataMapRequest.create("/auth").run {
dataMap.putString("token", token)
asPutDataRequest()
}
val putDataTask: Task<DataItem> = dataClient.putDataItem(putDataReq)
Wear OS অ্যাপে ডেটা পরিবর্তনের ইভেন্টগুলি শুনুন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:
val dataClient: DataClient = Wearable.getDataClient(context)
dataClient.addListener{ dataEvents ->
dataEvents.forEach { event ->
if (event.type == DataEvent.TYPE_CHANGED) {
val dataItemPath = event.dataItem.uri.path ?: ""
if (dataItemPath.startsWith("/auth")) {
val token = DataMapItem.fromDataItem(event.dataItem).dataMap.getString("token")
// Display an interstitial screen to notify the user that
// they're being signed in.
// Then, store the token and use it in network requests.
}
}
}
}
পরিধেয় ডেটা স্তর ব্যবহার সম্পর্কে আরও তথ্যের জন্য, Wear OS-এ ডেটা পাঠান এবং সিঙ্ক করুন দেখুন।
OAuth 2.0 ব্যবহার করুন
Wear OS দুটি OAuth 2.0-ভিত্তিক প্রবাহ সমর্থন করে, যা নিম্নলিখিত বিভাগগুলিতে বর্ণনা করা হয়েছে:
- কোড এক্সচেঞ্জ (PKCE) এর জন্য প্রুফ কী সহ অনুমোদন কোড অনুদান, যেমন RFC 7636 এ সংজ্ঞায়িত করা হয়েছে
- ডিভাইস অনুমোদন অনুদান (DAG), RFC 8628- এ সংজ্ঞায়িত
কোড এক্সচেঞ্জের জন্য প্রুফ কী (PKCE)
PKCE কার্যকরভাবে ব্যবহার করতে, RemoteAuthClient ব্যবহার করুন। তারপর, আপনার Wear OS অ্যাপ থেকে OAuth প্রদানকারীর কাছে একটি প্রমাণীকরণ অনুরোধ সম্পাদন করতে, একটি OAuthRequest অবজেক্ট তৈরি করুন। এই অবজেক্টটিতে একটি টোকেন এবং একটি CodeChallenge অবজেক্ট পাওয়ার জন্য আপনার OAuth এন্ডপয়েন্টের একটি URL থাকে।
নিম্নলিখিত কোডটি একটি প্রমাণীকরণ অনুরোধ তৈরির একটি উদাহরণ দেখায়:
val request = OAuthRequest.Builder(this.applicationContext)
.setAuthProviderUrl(Uri.parse("https://...."))
.setClientId(clientId)
.setCodeChallenge(codeChallenge)
.build()
auth অনুরোধ তৈরি করার পরে, sendAuthorizationRequest() পদ্ধতি ব্যবহার করে এটি companion অ্যাপে পাঠান:
val client = RemoteAuthClient.create(this)
client.sendAuthorizationRequest(request,
{ command -> command?.run() },
object : RemoteAuthClient.Callback() {
override fun onAuthorizationResponse(
request: OAuthRequest,
response: OAuthResponse
) {
// Extract the token from the response, store it, and use it in
// network requests.
}
override fun onAuthorizationError(errorCode: Int) {
// Handle any errors.
}
}
)
এই অনুরোধটি কম্প্যানিয়ন অ্যাপে একটি কল ট্রিগার করে, যা ব্যবহারকারীর মোবাইল ফোনের একটি ওয়েব ব্রাউজারে একটি অনুমোদন UI উপস্থাপন করে। OAuth 2.0 প্রদানকারী ব্যবহারকারীকে প্রমাণীকরণ করে এবং অনুরোধকৃত অনুমতিগুলির জন্য ব্যবহারকারীর সম্মতি গ্রহণ করে। প্রতিক্রিয়াটি স্বয়ংক্রিয়ভাবে তৈরি পুনঃনির্দেশ URL-এ পাঠানো হয়।
একটি সফল বা ব্যর্থ অনুমোদনের পরে, OAuth 2.0 সার্ভার অনুরোধে নির্দিষ্ট URL-এ পুনঃনির্দেশিত হয়। যদি ব্যবহারকারী অ্যাক্সেস অনুরোধটি অনুমোদন করেন, তাহলে প্রতিক্রিয়াটিতে একটি অনুমোদন কোড থাকে। যদি ব্যবহারকারী অনুরোধটি অনুমোদন না করেন, তাহলে প্রতিক্রিয়াটিতে একটি ত্রুটি বার্তা থাকে।
উত্তরটি একটি কোয়েরি স্ট্রিং আকারে এবং নিম্নলিখিত উদাহরণগুলির মধ্যে একটির মতো দেখাচ্ছে:
https://wear.googleapis.com/3p_auth/com.your.package.name?code=xyz
https://wear.googleapis-cn.com/3p_auth/com.your.package.name?code=xyz
এটি এমন একটি পৃষ্ঠা লোড করে যা ব্যবহারকারীকে কম্প্যানিয়ন অ্যাপে নির্দেশ করে। কম্প্যানিয়ন অ্যাপটি প্রতিক্রিয়া URL যাচাই করে এবং onAuthorizationResponse API ব্যবহার করে আপনার Wear OS অ্যাপে প্রতিক্রিয়া রিলে করে।
এরপর ওয়াচ অ্যাপটি অনুমোদন কোডের বিনিময়ে একটি অ্যাক্সেস টোকেন ব্যবহার করতে পারে।
ডিভাইস অনুমোদন অনুদান
ডিভাইস অথরাইজেশন গ্রান্ট ব্যবহার করার সময়, ব্যবহারকারী অন্য ডিভাইসে যাচাইকরণ URI খোলে। তারপর অথরাইজেশন সার্ভার তাদের অনুরোধটি অনুমোদন বা অস্বীকার করতে বলে।
এই প্রক্রিয়াটি সহজ করার জন্য, ব্যবহারকারীর জোড়া মোবাইল ডিভাইসে একটি ওয়েব পৃষ্ঠা খুলতে RemoteActivityHelper ব্যবহার করুন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:
// Request access from the authorization server and receive Device Authorization
// Response.
val verificationUri = "..." // Extracted from the Device Authorization Response.
RemoteActivityHelper.startRemoteActivity(
this,
Intent(Intent.ACTION_VIEW)
.addCategory(Intent.CATEGORY_BROWSABLE)
.setData(Uri.parse(verificationUri)),
null
)
// Poll the authorization server to find out if the user completed the user
// authorization step on their mobile device.
যদি আপনার iOS অ্যাপ থাকে, তাহলে টোকেন অনুমোদনের জন্য ব্রাউজারের উপর নির্ভর না করে আপনার অ্যাপে এই উদ্দেশ্যটি আটকাতে সর্বজনীন লিঙ্ক ব্যবহার করুন।
লিগ্যাসি থেকে দূরে সরে যান Google এর মাধ্যমে সাইন ইন করুন
ক্রেডেনশিয়াল ম্যানেজারে "সাইন ইন উইথ গুগল" বোতামের জন্য একটি ডেডিকেটেড ইন্টিগ্রেশন পয়েন্ট রয়েছে। পূর্বে, এই বোতামটি একটি অ্যাপের প্রমাণীকরণ UX-এর যেকোনো জায়গায় যোগ করা যেত, কিন্তু ক্রেডেনশিয়াল ম্যানেজারে এটি অন্তর্ভুক্ত হওয়ার সাথে সাথে, পুরানো বিকল্পটি এখন অবচিত।
// Define a basic SDK check.
fun isCredentialManagerAvailable(): Boolean {
return android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.VANILLA_ICE_CREAM
}
// Elsewhere in the code, use it to selectively disable the legacy option.
Button(
onClick = {
if (isCredentialManagerAvailable()) {
Log.w(TAG, "Devices on API level 35 or higher should use
Credential Manager for Sign in with Google")
} else {
navigateToSignInWithGoogle()
}},
enabled = !isCredentialManagerAvailable(),
label = { Text(text = stringResource(R.string.sign_in_with_google)) },
secondaryLabel = { Text(text = "Disabled on API level 35+")
}
)