Firebase Data Connect সাথে শক্তিশালী ক্লায়েন্ট-সাইড নিরাপত্তা প্রদান করে:
- মোবাইল এবং ওয়েব ক্লায়েন্ট অনুমোদন
- স্বতন্ত্র প্রশ্ন- এবং মিউটেশন-স্তরের অনুমোদন নিয়ন্ত্রণ
- Firebase App Check সহ অ্যাপ প্রত্যয়ন।
Data Connect এই নিরাপত্তা প্রসারিত করে:
- সার্ভার-সাইড অনুমোদন
- ফায়ারবেস প্রজেক্ট এবং ক্লাউড এসকিউএল ব্যবহারকারী নিরাপত্তা আইএএম-এর সাথে।
ক্লায়েন্ট প্রশ্ন এবং মিউটেশন অনুমোদন
Data Connect সম্পূর্ণরূপে Firebase Authentication সাথে একত্রিত, তাই আপনি সেই ব্যবহারকারীদের সম্পর্কে সমৃদ্ধ ডেটা ব্যবহার করতে পারেন যারা আপনার ডিজাইনে আপনার ডেটা (প্রমাণিকরণ) অ্যাক্সেস করছে সেই ব্যবহারকারীরা কোন ডেটা অ্যাক্সেস করতে পারে (অনুমোদন)।
Data Connect প্রশ্ন এবং মিউটেশনের জন্য একটি @auth
নির্দেশনা প্রদান করে যা আপনাকে অপারেশন অনুমোদন করার জন্য প্রয়োজনীয় প্রমাণীকরণের স্তর সেট করতে দেয়। এই নির্দেশিকাটি উদাহরণ সহ @auth
নির্দেশিকা প্রবর্তন করে ।
উপরন্তু, Data Connect মিউটেশনে এমবেড করা প্রশ্নগুলির সম্পাদনকে সমর্থন করে, তাই আপনি আপনার ডাটাবেসে সংরক্ষিত অতিরিক্ত অনুমোদনের মানদণ্ড পুনরুদ্ধার করতে পারেন, এবং এনক্লোসিং মিউটেশন অনুমোদিত কিনা তা সিদ্ধান্ত নিতে @check
নির্দেশাবলীতে সেই মানদণ্ডগুলি ব্যবহার করতে পারেন। এই অনুমোদনের ক্ষেত্রে, @redact
নির্দেশ আপনাকে ওয়্যার প্রোটোকলে ক্লায়েন্টদের কাছে কোয়েরির ফলাফল ফেরত দেওয়া হবে কিনা এবং জেনারেট করা SDK-এ এমবেডেড ক্যোয়ারী বাদ দেওয়া হবে কিনা তা নিয়ন্ত্রণ করতে দেয়। উদাহরণ সহ এই নির্দেশাবলীর ভূমিকা খুঁজুন।
@auth
নির্দেশ বুঝুন
আপনি অনেকগুলি সাধারণ অ্যাক্সেসের পরিস্থিতি কভার করে এমন কয়েকটি প্রিসেট অ্যাক্সেস লেভেলের একটি অনুসরণ করতে @auth
নির্দেশকে প্যারামিটারাইজ করতে পারেন। এই স্তরগুলি PUBLIC
(যা কোনো প্রকারের প্রমাণীকরণ ছাড়াই সমস্ত ক্লায়েন্টের কাছ থেকে প্রশ্ন এবং মিউটেশনের অনুমতি দেয়) থেকে NO_ACCESS
পর্যন্ত (যা ফায়ারবেস অ্যাডমিন SDK ব্যবহার করে বিশেষ সুবিধাপ্রাপ্ত সার্ভার পরিবেশের বাইরে প্রশ্ন এবং মিউটেশন অনুমোদন করে)। এই স্তরগুলির প্রতিটি Firebase Authentication দ্বারা প্রদত্ত প্রমাণীকরণ প্রবাহের সাথে সম্পর্কযুক্ত।
স্তর | সংজ্ঞা |
---|---|
PUBLIC | অপারেশনটি প্রমাণীকরণ সহ বা ছাড়াই যে কেউ সম্পাদন করতে পারে। |
PUBLIC | অপারেশনটি প্রমাণীকরণ সহ বা ছাড়াই যে কেউ সম্পাদন করতে পারে। |
USER_ANON | Firebase Authentication মাধ্যমে যারা বেনামে লগ ইন করেছেন তাদের সহ যেকোন চিহ্নিত ব্যবহারকারী, ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত। |
USER | যে কোনো ব্যবহারকারী যে Firebase Authentication মাধ্যমে লগ ইন করেছেন তারা বেনামী সাইন-ইন ব্যবহারকারীদের ছাড়া ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত। |
USER_EMAIL_VERIFIED | যে কোনো ব্যবহারকারী যিনি একটি যাচাইকৃত ইমেল ঠিকানা দিয়ে Firebase Authentication মাধ্যমে লগ ইন করেছেন তিনি ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত৷ |
NO_ACCESS | এই অপারেশনটি অ্যাডমিন SDK প্রসঙ্গের বাইরে চালানো যাবে না। |
প্রারম্ভিক বিন্দু হিসাবে এই প্রিসেট অ্যাক্সেস লেভেলগুলি ব্যবহার করে, আপনি সার্ভারে where
ফিল্টার এবং কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (CEL) এক্সপ্রেশনগুলি মূল্যায়ন করা হয় তা ব্যবহার করে @auth
নির্দেশে জটিল এবং শক্তিশালী অনুমোদন চেকগুলি সংজ্ঞায়িত করতে পারেন৷
সাধারণ অনুমোদনের পরিস্থিতি বাস্তবায়ন করতে @auth
নির্দেশিকা ব্যবহার করুন
প্রিসেট অ্যাক্সেস লেভেল হল অনুমোদনের সূচনা বিন্দু ।
USER
অ্যাক্সেস স্তরটি শুরু করার জন্য সবচেয়ে ব্যাপকভাবে দরকারী মৌলিক স্তর।
সম্পূর্ণ সুরক্ষিত অ্যাক্সেস USER
লেভেল প্লাস ফিল্টার এবং এক্সপ্রেশন তৈরি করবে যা ব্যবহারকারীর অ্যাট্রিবিউট, রিসোর্স অ্যাট্রিবিউট, ভূমিকা এবং অন্যান্য চেক চেক করে। USER_ANON
এবং USER_EMAIL_VERIFIED
স্তরগুলি হল USER
ক্ষেত্রের বিভিন্নতা৷
এক্সপ্রেশন সিনট্যাক্স আপনাকে একটি auth
অবজেক্ট ব্যবহার করে ডেটা মূল্যায়ন করতে দেয় যা অপারেশনের সাথে পাস করা প্রমাণীকরণ ডেটা উপস্থাপন করে, প্রমাণীকরণ টোকেনে স্ট্যান্ডার্ড ডেটা এবং টোকেনে কাস্টম ডেটা উভয়ই। auth
অবজেক্টে উপলব্ধ ক্ষেত্রগুলির তালিকার জন্য, রেফারেন্স বিভাগটি দেখুন।
অবশ্যই এমন কিছু ব্যবহার আছে যেখানে PUBLIC
হল সঠিক অ্যাক্সেস লেভেল দিয়ে শুরু করা। আবার, একটি অ্যাক্সেস স্তর সর্বদা একটি সূচনা বিন্দু, এবং শক্তিশালী নিরাপত্তার জন্য অতিরিক্ত ফিল্টার এবং অভিব্যক্তি প্রয়োজন।
এই নির্দেশিকাটি এখন USER
এবং PUBLIC
এ কীভাবে তৈরি করা যায় তার উদাহরণ দেয়৷
একটি প্রেরণাদায়ক উদাহরণ
নিম্নলিখিত সর্বোত্তম অনুশীলনের উদাহরণগুলি একটি পেমেন্ট প্ল্যানের পিছনে লক করা নির্দিষ্ট সামগ্রী সহ একটি ব্লগিং প্ল্যাটফর্মের জন্য নিম্নলিখিত স্কিমাকে উল্লেখ করে৷
এই ধরনের একটি প্ল্যাটফর্ম সম্ভবত Users
এবং Posts
মডেল হবে।
type User @table(key: "uid") {
uid: String!
name: String
birthday: Date
createdAt: Timestamp! @default(expr: "request.time")
}
type Post @table {
author: User!
text: String!
# "one of 'draft', 'public', or 'pro'"
visibility: String! @default(value: "draft")
# "the time at which the post should be considered published. defaults to
# immediately"
publishedAt: Timestamp! @default(expr: "request.time")
createdAt: Timestamp! @default(expr: "request.time")
updatedAt: Timestamp! @default(expr: "request.time")
}
ব্যবহারকারীর মালিকানাধীন সম্পদ
Firebase সুপারিশ করে যে আপনি এমন ফিল্টার এবং অভিব্যক্তি লিখুন যা একটি সংস্থানের ব্যবহারকারীর মালিকানা পরীক্ষা করে, নিম্নলিখিত ক্ষেত্রে, Posts
মালিকানা।
নিম্নলিখিত উদাহরণগুলিতে, প্রমাণীকরণ টোকেন থেকে ডেটা পড়া এবং এক্সপ্রেশন ব্যবহার করে তুলনা করা হয়। সাধারণ প্যাটার্ন হল where: {authorUid: {eq_expr: "auth.uid"}}
প্রমাণীকরণ টোকেনে পাস করা auth.uid
(ইউজার আইডি) এর সাথে একটি সংরক্ষিত authorUid
তুলনা করতে।
তৈরি করুন
এই অনুমোদনের অনুশীলনটি পরবর্তী অনুমোদন পরীক্ষায় তুলনা করার অনুমতি দেওয়ার জন্য প্রতিটি নতুন Post
একটি authorUid
ক্ষেত্র হিসাবে auth.uid
যোগ করার মাধ্যমে শুরু হয়।
# Create a new post as the current user
mutation CreatePost($text: String!, $visibility: String) @auth(level: USER) {
post_insert(data: {
# set the author's uid to the current user uid
authorUid_expr: "auth.uid"
text: $text
visibility: $visibility
})
}
আপডেট
যখন কোনো ক্লায়েন্ট কোনো Post
আপডেট করার চেষ্টা করে, আপনি সঞ্চিত authorUid
বিরুদ্ধে পাস করা auth.uid
পরীক্ষা করতে পারেন।
# Update one of the current user's posts
mutation UpdatePost($id: UUID!, $text: String, $visibility: String) @auth(level:USER) {
post_update(
# only update posts whose author is the current user
first: { where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}
}}
data: {
text: $text
visibility: $visibility
# insert the current server time for updatedAt
updatedAt_expr: "request.time"
}
)
}
মুছে দিন
একই কৌশল মুছে ফেলার ক্রিয়াকলাপ অনুমোদন করতে ব্যবহৃত হয়।
# Delete one of the current user's posts
mutation DeletePost($id: UUID!) @auth(level: USER) {
post_delete(
# only delete posts whose author is the current user
first: { where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}
}}
)
}
# Common display information for a post
fragment DisplayPost on Post {
id, text, createdAt, updatedAt
author { uid, name }
}
তালিকা
# List all posts belonging to the current user
query ListMyPosts @auth(level: USER) {
posts(where: {
userUid: {eq_expr: "auth.uid"}
}) {
# See the fragment above
...DisplayPost
# also show visibility since it is user-controlled
visibility
}
}
পান
# Get a post only if it belongs to the current user
query GetMyPost($id: UUID!) @auth(level: USER) {
post(key: {id: $id},
first: {where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}}
}}, {
# See the fragment above
...DisplayPost
# also show visibility since it is user-controlled
visibility
}
}
ফিল্টার ডেটা
Data Connect অনুমোদন ব্যবস্থা আপনাকে PUBLIC
মতো প্রিসেট অ্যাক্সেস লেভেলের পাশাপাশি প্রমাণীকরণ টোকেন থেকে ডেটা ব্যবহার করে অত্যাধুনিক ফিল্টার লিখতে দেয়।
অনুমোদন সিস্টেম আপনাকে শুধুমাত্র অভিব্যক্তি ব্যবহার করতে দেয়, বেস অ্যাক্সেস লেভেল ছাড়াই, যেমনটি নিম্নলিখিত কয়েকটি উদাহরণে দেখানো হয়েছে।
সম্পদ বৈশিষ্ট্য দ্বারা ফিল্টার
এখানে, অনুমোদন প্রমাণীকরণ টোকেনের উপর ভিত্তি করে নয় যেহেতু বেস নিরাপত্তা স্তরটি PUBLIC
এ সেট করা আছে৷ কিন্তু, আমরা সুস্পষ্টভাবে আমাদের ডাটাবেসে রেকর্ড সেট করতে পারি পাবলিক অ্যাক্সেসের জন্য উপযুক্ত হিসাবে; অনুমান করুন আমাদের ডাটাবেসে Post
রেকর্ড রয়েছে যার visibility
"পাবলিক" এ সেট করা আছে।
# List all posts marked as 'public' visibility
query ListPublicPosts @auth(level: PUBLIC) {
posts(where: {
# Test that visibility is "public"
visibility: {eq: "public"}
# Only display articles that are already published
publishedAt: {lt_expr: "request.time"}
}) {
# see the fragment above
...DisplayPost
}
}
ব্যবহারকারীর দাবি অনুযায়ী ফিল্টার করুন
এখানে, ধরে নিন আপনি কাস্টম ব্যবহারকারীর দাবিগুলি সেট আপ করেছেন যা প্রমাণীকরণ টোকেনে পাস করে আপনার অ্যাপের জন্য একটি "প্রো" প্ল্যানে ব্যবহারকারীদের সনাক্ত করার জন্য, প্রমাণীকরণ টোকেনে একটি auth.token.plan
ক্ষেত্রের সাথে পতাকাঙ্কিত। আপনার অভিব্যক্তি এই ক্ষেত্রের বিরুদ্ধে পরীক্ষা করতে পারেন.
# List all public or pro posts, only permitted if user has "pro" plan claim
query ProListPosts @auth(expr: "auth.token.plan == 'pro'") {
posts(where: {
# display both public posts and "pro" posts
visibility: {in: ['public', 'pro']},
# only display articles that are already published
publishedAt: {lt_expr: "request.time"},
}) {
# see the fragment above
...DisplayPost
# show visibility so pro users can see which posts are pro\
visibility
}
}
অর্ডার + সীমা অনুসারে ফিল্টার করুন
অথবা আবার, আপনি "প্রো" ব্যবহারকারীদের জন্য উপলব্ধ সামগ্রী সনাক্ত করতে Post
রেকর্ডগুলিতে visibility
সেট করতে পারেন, তবে ডেটার পূর্বরূপ বা টিজার তালিকার জন্য, ফেরত আসা রেকর্ডের সংখ্যা আরও সীমাবদ্ধ করুন৷
# Show 2 oldest Pro post as a preview
query ProTeaser @auth(level: USER) {
posts(
where: {
# show only pro posts
visibility: {eq: "pro"}
# that have already been published more than 30 days ago
publishedAt: {lt_time: {now: true, sub: {days: 30}}}
},
# order by publish time
orderBy: [{publishedAt: DESC}],
# only return two posts
limit: 2
) {
# See the fragment above
...DisplayPost
}
}
ভূমিকা দ্বারা ফিল্টার
যদি আপনার কাস্টম দাবি একটি admin
ভূমিকা সংজ্ঞায়িত করে, আপনি সেই অনুযায়ী অপারেশন পরীক্ষা এবং অনুমোদন করতে পারেন।
# List all posts unconditionally iff the current user has an admin claim
query AdminListPosts @auth(expr: "auth.token.admin == true") {
posts { ...DisplayPost }
}
@check
এবং @redact
নির্দেশাবলী বুঝুন
@check
নির্দেশিকা যাচাই করে যে নির্দিষ্ট ক্ষেত্রগুলি প্রশ্নের ফলাফলগুলিতে উপস্থিত রয়েছে৷ একটি কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিইএল) এক্সপ্রেশন ফিল্ডের মান পরীক্ষা করতে ব্যবহৃত হয়। নির্দেশের ডিফল্ট আচরণ হল null
-valued নোডগুলি পরীক্ষা করা এবং প্রত্যাখ্যান করা।
@redact
নির্দেশিকা ক্লায়েন্টের প্রতিক্রিয়ার একটি অংশকে সংশোধন করে। সংশোধিত ক্ষেত্রগুলি এখনও পার্শ্ব প্রতিক্রিয়াগুলির জন্য মূল্যায়ন করা হয় (ডেটা পরিবর্তন এবং @check
সহ) এবং ফলাফলগুলি এখনও CEL এক্সপ্রেশনের পরবর্তী ধাপগুলিতে উপলব্ধ।
Data Connect এ, @check
এবং @redact
নির্দেশাবলী প্রায়শই অনুমোদন চেকের প্রসঙ্গে ব্যবহৃত হয়; অনুমোদন ডেটা লুকআপের আলোচনা পড়ুন।
অনুমোদনের ডেটা দেখতে @check
চেক এবং @redact
নির্দেশিকা যোগ করুন
একটি সাধারণ অনুমোদন ব্যবহারের ক্ষেত্রে আপনার ডাটাবেসে কাস্টম অনুমোদনের ভূমিকাগুলি সংরক্ষণ করা জড়িত, উদাহরণস্বরূপ একটি বিশেষ অনুমতি সারণীতে, এবং ডেটা তৈরি, আপডেট বা মুছে ফেলার জন্য মিউটেশন অনুমোদন করতে সেই ভূমিকাগুলি ব্যবহার করে৷
অনুমোদন ডেটা লুকআপ ব্যবহার করে, আপনি একটি userID এর উপর ভিত্তি করে ভূমিকার জন্য অনুসন্ধান করতে পারেন এবং মিউটেশন অনুমোদিত কিনা তা নির্ধারণ করতে CEL এক্সপ্রেশন ব্যবহার করতে পারেন। উদাহরণস্বরূপ, আপনি একটি UpdateMovieTitle
মিউটেশন লিখতে চাইতে পারেন যা একটি অনুমোদিত ক্লায়েন্টকে মুভির শিরোনাম আপডেট করতে দেয়।
এই আলোচনার বাকি অংশের জন্য, ধরে নিন মুভি রিভিউ অ্যাপ ডাটাবেস একটি MoviePermission
টেবিলে একটি অনুমোদনের ভূমিকা সঞ্চয় করে।
# MoviePermission
# Suppose a user has an authorization role with respect to records in the Movie table
type MoviePermission @table(key: ["movie", "user"]) {
movie: Movie! # implies another field: movieId: UUID!
user: User!
role: String!
}
মিউটেশনে ব্যবহার করুন
নিম্নলিখিত উদাহরণ বাস্তবায়নে, UpdateMovieTitle
মিউটেশনে MoviePermission
থেকে ডেটা পুনরুদ্ধার করার জন্য একটি query
ক্ষেত্র রয়েছে এবং অপারেশনটি নিরাপদ এবং শক্তিশালী তা নিশ্চিত করার জন্য নিম্নলিখিত নির্দেশাবলী রয়েছে:
- সমস্ত অনুমোদনের প্রশ্ন এবং চেক সম্পূর্ণ হয়েছে বা পারমাণবিকভাবে ব্যর্থ হয়েছে তা নিশ্চিত করার জন্য একটি
@transaction
নির্দেশিকা। - প্রতিক্রিয়া থেকে প্রশ্নের ফলাফল বাদ দেওয়ার জন্য
@redact
নির্দেশিকা, যার অর্থ আমাদের অনুমোদনের পরীক্ষা Data Connect সার্ভারে সঞ্চালিত হয় কিন্তু সংবেদনশীল ডেটা ক্লায়েন্টের কাছে প্রকাশ করা হয় না। ক্যোয়ারী ফলাফলে অনুমোদনের যুক্তির মূল্যায়ন করার জন্য
@check
নির্দেশাবলীর এক জোড়া, যেমন পরীক্ষা করা যে প্রদত্ত ইউজারআইডি পরিবর্তন করার জন্য উপযুক্ত ভূমিকা রয়েছে।
mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query @redact {
moviePermission( # Look up a join table called MoviePermission with a compound key.
key: {movieId: $movieId, userId_expr: "auth.uid"}
# Step 1a: Use @check to test if the user has any role associated with the movie
# Here the `this` binding refers the lookup result, i.e. a MoviePermission object or null
# The `this != null` expression could be omitted since rejecting on null is default behavior
) @check(expr: "this != null", message: "You do not have access to this movie") {
# Step 1b: Check if the user has the editor role for the movie
# Next we execute another @check; now `this` refers to the contents of the `role` field
role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
প্রশ্নাবলী ব্যবহার করুন
ভূমিকা বা অন্যান্য বিধিনিষেধের উপর ভিত্তি করে প্রশ্নগুলিকে সীমাবদ্ধ করতে অনুমোদন ডেটা লুকআপগুলিও কার্যকর।
নিম্নলিখিত উদাহরণে, যেটি MoviePermission
স্কিমাও ব্যবহার করে, প্রশ্নটি পরীক্ষা করে যে একজন অনুরোধকারীর একটি উপযুক্ত "প্রশাসক" ভূমিকা আছে কিনা তা ব্যবহারকারীদের দেখার জন্য যারা একটি চলচ্চিত্র সম্পাদনা করতে পারে৷
query GetMovieEditors($movieId: UUID!) @auth(level: PUBLIC) {
moviePermission(key: { movieId: $movieId, userId_expr: "auth.uid" }) @redact {
role @check(expr: "this == 'admin'", message: "You must be an admin to view all editors of a movie.")
}
moviePermissions(where: { movieId: { eq: $movieId }, role: { eq: "editor" } }) {
user {
id
username
}
}
}
অনুমোদন এড়াতে অ্যান্টিপ্যাটার্নস
পূর্ববর্তী বিভাগে @auth
নির্দেশিকা ব্যবহার করার সময় অনুসরণ করা নিদর্শনগুলি কভার করে৷
এড়ানোর জন্য আপনার গুরুত্বপূর্ণ অ্যান্টিপ্যাটার্ন সম্পর্কেও সচেতন হওয়া উচিত।
ক্যোয়ারী এবং মিউটেশন আর্গুমেন্টে ব্যবহারকারীর অ্যাট্রিবিউট আইডি এবং প্রমাণীকরণ টোকেন প্যারামিটার পাস করা এড়িয়ে চলুন
Firebase Authentication হল প্রমাণীকরণের প্রবাহ উপস্থাপন করার জন্য এবং নিবন্ধিত ব্যবহারকারী আইডি এবং প্রমাণীকরণ টোকেনে সংরক্ষিত অসংখ্য ক্ষেত্রগুলির মতো প্রমাণীকরণ ডেটা সুরক্ষিতভাবে ক্যাপচার করার জন্য একটি শক্তিশালী টুল।
ক্যোয়ারী এবং মিউটেশন আর্গুমেন্টে ব্যবহারকারী আইডি এবং প্রমাণীকরণ টোকেন ডেটা পাস করার জন্য এটি একটি প্রস্তাবিত অনুশীলন নয়।
# Antipattern!
# This incorrectly allows any user to view any other user's posts
query AllMyPosts($userId: String!) @auth(level: USER) {
posts(where: {authorUid: {eq: $userId}}) {
id, text, createdAt
}
}
কোনো ফিল্টার ছাড়াই USER
অ্যাক্সেস লেভেল ব্যবহার করা এড়িয়ে চলুন
নির্দেশিকায় বেশ কয়েকবার আলোচনা করা হয়েছে, USER
, USER_ANON
, USER_EMAIL_VERIFIED
এর মত মূল অ্যাক্সেসের স্তরগুলি হল বেসলাইন এবং অনুমোদন চেকগুলির জন্য শুরুর পয়েন্ট, যা ফিল্টার এবং অভিব্যক্তিগুলির সাথে উন্নত করা যায়৷ সংশ্লিষ্ট ফিল্টার বা অভিব্যক্তি ছাড়াই এই স্তরগুলি ব্যবহার করা যা চেক করে যে কোন ব্যবহারকারী অনুরোধটি সম্পাদন করছে তা মূলত PUBLIC
স্তর ব্যবহার করার সমতুল্য৷
# Antipattern!
# This incorrectly allows any user to view all documents
query ListDocuments @auth(level: USER) {
documents {
id
title
text
}
}
প্রোটোটাইপিংয়ের জন্য PUBLIC
বা USER
অ্যাক্সেস লেভেল ব্যবহার করা এড়িয়ে চলুন
বিকাশের গতি বাড়ানোর জন্য, সমস্ত ক্রিয়াকলাপগুলিকে PUBLIC
অ্যাক্সেস লেভেলে বা USER
অ্যাক্সেস লেভেলে সেট করার জন্য প্রলুব্ধ হতে পারে যাতে সমস্ত ক্রিয়াকলাপ অনুমোদন করা যায় এবং আপনাকে দ্রুত আপনার কোড পরীক্ষা করতে দেয়৷
আপনি যখন এইভাবে খুব প্রাথমিক প্রোটোটাইপিং করেছেন, তখন NO_ACCESS
থেকে PUBLIC
এবং USER
স্তরের সাথে উত্পাদন-প্রস্তুত অনুমোদনে স্যুইচ করা শুরু করুন৷ যাইহোক, এই নির্দেশিকায় দেখানো হিসাবে অতিরিক্ত যুক্তি যোগ না করে তাদেরকে PUBLIC
বা USER
হিসাবে স্থাপন করবেন না।
# Antipattern!
# This incorrectly allows anyone to delete any post
mutation DeletePost($id: UUID!) @auth(level: PUBLIC) {
post: post_delete(
id: $id,
)
}
অ্যাপের সত্যায়নের জন্য Firebase App Check ব্যবহার করুন
প্রমাণীকরণ এবং অনুমোদন Data Connect নিরাপত্তার গুরুত্বপূর্ণ উপাদান। অ্যাপ্লিকেশান প্রত্যয়নের সাথে মিলিত প্রমাণীকরণ এবং অনুমোদন একটি খুব শক্তিশালী সুরক্ষা সমাধান তৈরি করে।
Firebase App Check মাধ্যমে প্রত্যয়িতকরণের মাধ্যমে, আপনার অ্যাপ চালানো ডিভাইসগুলি এমন একটি অ্যাপ বা ডিভাইসের প্রত্যয়ন প্রদানকারী ব্যবহার করবে যা প্রমাণ করে যে Data Connect অপারেশনগুলি আপনার প্রামাণিক অ্যাপ থেকে এবং অনুরোধগুলি একটি খাঁটি, অপ্রতিরোধ্য ডিভাইস থেকে উদ্ভূত হয়েছে। এই প্রত্যয়নটি আপনার অ্যাপ Data Connect করা প্রতিটি অনুরোধের সাথে সংযুক্ত থাকে।
কীভাবে App Check ফর Data Connect সক্ষম করবেন এবং আপনার অ্যাপে এর ক্লায়েন্ট SDK অন্তর্ভুক্ত করবেন তা জানতে, App Check ওভারভিউ দেখুন ।
@auth(level)
নির্দেশের জন্য প্রমাণীকরণ স্তর
নিম্নলিখিত সারণীতে সমস্ত স্ট্যান্ডার্ড অ্যাক্সেস লেভেল এবং তাদের CEL সমতুল্য তালিকা রয়েছে। প্রমাণীকরণ স্তরগুলি বিস্তৃত থেকে সংকীর্ণ পর্যন্ত তালিকাভুক্ত করা হয়েছে -- প্রতিটি স্তর নিম্নলিখিত স্তরগুলির সাথে মেলে এমন সমস্ত ব্যবহারকারীকে অন্তর্ভুক্ত করে৷
স্তর | সংজ্ঞা |
---|---|
PUBLIC | অপারেশনটি প্রমাণীকরণ সহ বা ছাড়াই যে কেউ সম্পাদন করতে পারে। বিবেচ্য বিষয়: ডেটা যেকোনো ব্যবহারকারীর দ্বারা পড়া বা পরিবর্তন করা যেতে পারে। Firebase পণ্য বা মিডিয়া তালিকার মতো সর্বজনীনভাবে ব্রাউজযোগ্য ডেটার জন্য অনুমোদনের এই স্তরের সুপারিশ করে। সেরা অনুশীলন উদাহরণ এবং বিকল্প দেখুন. @auth(expr: "true") @auth ফিল্টার এবং এক্সপ্রেশন এই অ্যাক্সেস স্তরের সাথে একত্রে ব্যবহার করা যাবে না। এই ধরনের যেকোনো এক্সপ্রেশন 400 খারাপ অনুরোধ ত্রুটির সাথে ব্যর্থ হবে। |
USER_ANON | Firebase Authentication মাধ্যমে যারা বেনামে লগ ইন করেছেন তাদের সহ যেকোন চিহ্নিত ব্যবহারকারী, ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত। দ্রষ্টব্য: USER_ANON হল USER এর একটি সুপারসেট৷বিবেচ্য বিষয়: নোট করুন যে অনুমোদনের এই স্তরের জন্য আপনাকে অবশ্যই আপনার প্রশ্ন এবং মিউটেশনগুলি সাবধানে ডিজাইন করতে হবে। এই স্তরটি ব্যবহারকারীকে Authentication সাথে বেনামে লগ ইন করার অনুমতি দেয় (শুধুমাত্র একটি ব্যবহারকারীর ডিভাইসে স্বয়ংক্রিয় সাইন-ইন বাঁধা) এবং এটি নিজে থেকে অন্যান্য পরীক্ষা করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলন উদাহরণ এবং বিকল্প দেখুন. যেহেতু Authentication বেনামী লগইন প্রবাহ একটি uid ইস্যু করে, তাই USER_ANON স্তরটি এর সমতুল্য@auth(expr: "auth.uid != nil") |
USER | যে কোনো ব্যবহারকারী যে Firebase Authentication মাধ্যমে লগ ইন করেছেন তারা বেনামী সাইন-ইন ব্যবহারকারীদের ছাড়া ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত। বিবেচ্য বিষয়: নোট করুন যে অনুমোদনের এই স্তরের জন্য আপনাকে অবশ্যই আপনার প্রশ্ন এবং মিউটেশনগুলি সাবধানে ডিজাইন করতে হবে। এই স্তরটি শুধুমাত্র যাচাই করে যে ব্যবহারকারী Authentication সাথে লগ ইন করেছেন এবং নিজে থেকে অন্য পরীক্ষাগুলি সম্পাদন করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলন উদাহরণ এবং বিকল্প দেখুন. @auth(expr: "auth.uid != nil && auth.token.firebase.sign_in_provider != 'anonymous'")" এর সমতুল্য |
USER_EMAIL_VERIFIED | যে কোনো ব্যবহারকারী যিনি একটি যাচাইকৃত ইমেল ঠিকানা দিয়ে Firebase Authentication মাধ্যমে লগ ইন করেছেন তিনি ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত৷ বিবেচনা: যেহেতু ইমেল যাচাইকরণ Authentication ব্যবহার করে সঞ্চালিত হয়, এটি আরও শক্তিশালী Authentication পদ্ধতির উপর ভিত্তি করে, এইভাবে এই স্তরটি USER বা USER_ANON তুলনায় অতিরিক্ত নিরাপত্তা প্রদান করে। এই স্তরটি শুধুমাত্র যাচাই করে যে ব্যবহারকারী একটি যাচাইকৃত ইমেলের মাধ্যমে Authentication সাথে লগ ইন করেছেন এবং নিজে থেকে অন্য পরীক্ষাগুলি সম্পাদন করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলন উদাহরণ এবং বিকল্প দেখুন.@auth(expr: "auth.uid != nil && auth.token.email_verified")" |
NO_ACCESS | এই অপারেশনটি অ্যাডমিন SDK প্রসঙ্গের বাইরে চালানো যাবে না।@auth(expr: "false") |
@auth(expr)
এবং @check(expr)
এর জন্য CEL রেফারেন্স
এই গাইডের অন্য কোথাও উদাহরণে দেখানো হয়েছে, আপনি @auth(expr:)
এবং @check
নির্দেশাবলী ব্যবহার করে Data Connect অনুমোদন নিয়ন্ত্রণ করতে কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (CEL) এ সংজ্ঞায়িত অভিব্যক্তি ব্যবহার করতে পারেন এবং ব্যবহার করা উচিত।
এই বিভাগটি এই নির্দেশাবলীর জন্য অভিব্যক্তি তৈরি করার জন্য প্রাসঙ্গিক CEL সিনট্যাক্স কভার করে।
CEL এর জন্য সম্পূর্ণ রেফারেন্স তথ্য CEL স্পেসিফিকেশনে প্রদান করা হয়েছে।
পরীক্ষা ভেরিয়েবল প্রশ্ন এবং মিউটেশন পাস
@auth(expr)
সিনট্যাক্স আপনাকে প্রশ্ন এবং মিউটেশন থেকে ভেরিয়েবল অ্যাক্সেস এবং পরীক্ষা করার অনুমতি দেয়।
উদাহরণস্বরূপ, আপনি একটি অপারেশন ভেরিয়েবল অন্তর্ভুক্ত করতে পারেন, যেমন $status
, vars.status
ব্যবহার করে।
mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")
এক্সপ্রেশনের জন্য উপলভ্য ডেটা
উভয় @auth(expr:)
এবং @check(expr:)
CEL অভিব্যক্তি নিম্নলিখিত মূল্যায়ন করতে পারে:
-
request.operationName
-
vars
(request.variables
এর উপনাম) -
auth
(request.auth
এর জন্য উপনাম)
উপরন্তু, @check(expr:)
অভিব্যক্তি মূল্যায়ন করতে পারে:
-
this
(বর্তমান ক্ষেত্রের মান)
request.operationName অবজেক্ট
request.operarationName
অবজেক্ট অপারেশনের ধরন সঞ্চয় করে, হয় প্রশ্ন বা মিউটেশন।
vars
বস্তু
vars
অবজেক্ট আপনার এক্সপ্রেশনগুলিকে আপনার ক্যোয়ারী বা মিউটেশনে পাস করা সমস্ত ভেরিয়েবল অ্যাক্সেস করতে দেয়।
আপনি vars.<variablename>
ব্যবহার করতে পারেন সম্পূর্ণরূপে-যোগ্য request.variables.<variablename>
:
# The following are equivalent
mutation StringType($v: String!) @auth(expr: "vars.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")
auth
অবজেক্ট
Authentication আপনার ডেটা অ্যাক্সেসের অনুরোধকারী ব্যবহারকারীদের সনাক্ত করে এবং সেই তথ্যটিকে একটি বস্তু হিসাবে প্রদান করে যা আপনি আপনার অভিব্যক্তিতে তৈরি করতে পারেন।
আপনার ফিল্টার এবং এক্সপ্রেশনে, আপনি request.auth
এর জন্য একটি উপনাম হিসাবে auth
ব্যবহার করতে পারেন।
auth অবজেক্টে নিম্নলিখিত তথ্য রয়েছে:
-
uid
: একটি অনন্য ব্যবহারকারী আইডি, অনুরোধকারী ব্যবহারকারীকে বরাদ্দ করা হয়েছে। -
token
: Authentication দ্বারা সংগৃহীত মানগুলির একটি মানচিত্র।
auth.token
এর বিষয়বস্তু সম্পর্কে আরও বিশদ বিবরণের জন্য প্রমাণীকরণ টোকেনে ডেটা দেখুন
this
বাঁধাই
this
বাঁধাই সেই ক্ষেত্রের মূল্যায়ন করে যেখানে @check
নির্দেশিকা সংযুক্ত আছে। একটি মৌলিক ক্ষেত্রে, আপনি একক-মূল্যবান ক্যোয়ারী ফলাফল মূল্যায়ন করতে পারেন।
mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query @redact {
moviePermission( # Look up a join table called MoviePermission with a compound key.
key: {movieId: $movieId, userId_expr: "auth.uid"}
) {
# Check if the user has the editor role for the movie. `this` is the string value of `role`.
# If the parent moviePermission is null, the @check will also fail automatically.
role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
যদি প্রত্যাবর্তিত ক্ষেত্রটি একাধিকবার ঘটে কারণ কোনো পূর্বপুরুষ একটি তালিকা, প্রতিটি ঘটনা প্রতিটি মানের সাথে this
আবদ্ধ করে পরীক্ষা করা হয়।
কোনো প্রদত্ত পথের জন্য, যদি কোনো পূর্বপুরুষ null
বা []
হয়, তাহলে ক্ষেত্রে পৌঁছানো যাবে না এবং সেই পথের জন্য CEL মূল্যায়ন বাদ দেওয়া হবে। অন্য কথায়, মূল্যায়ন তখনই সঞ্চালিত হয় যখন this
null
বা নন- null
, কিন্তু কখনই undefined
।
যখন ক্ষেত্র নিজেই একটি তালিকা বা বস্তু হয়, this
একই কাঠামো অনুসরণ করে (অবজেক্টের ক্ষেত্রে নির্বাচিত সমস্ত ডিসেন্ডেন্ট সহ), যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে।
mutation UpdateMovieTitle2($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query {
moviePermissions( # Now we query for a list of all matching MoviePermissions.
where: {movieId: {eq: $movieId}, userId: {eq_expr: "auth.uid"}}
# This time we execute the @check on the list, so `this` is the list of objects.
# We can use the `.exists` macro to check if there is at least one matching entry.
) @check(expr: "this.exists(p, p.role == 'editor')", message: "You must be an editor of this movie to update title") {
role
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
জটিল অভিব্যক্তি বাক্য গঠন
আপনি &&
এবং ||
এর সাথে একত্রিত করে আরও জটিল অভিব্যক্তি লিখতে পারেন অপারেটর
mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (vars.username == 'joe')")
নিম্নলিখিত বিভাগে সমস্ত উপলব্ধ অপারেটর বর্ণনা করা হয়েছে.
অপারেটর এবং অপারেটর অগ্রাধিকার
অপারেটর এবং তাদের সংশ্লিষ্ট অগ্রাধিকারের জন্য একটি রেফারেন্স হিসাবে নিম্নলিখিত টেবিলটি ব্যবহার করুন।
প্রদত্ত নির্বিচারে অভিব্যক্তি a
এবং b
, একটি ক্ষেত্র f
, এবং একটি সূচক i
.
অপারেটর | বর্ণনা | সহযোগীতা |
---|---|---|
a[i] a() af | সূচক, কল, ক্ষেত্র অ্যাক্সেস | বাম থেকে ডান |
!a -a | ইউনারি নেগেটিভ | ডান থেকে বাম |
a/ba%ba*b | মাল্টিপ্লেটিভ অপারেটর | বাম থেকে ডান |
a+b ab | সংযোজন অপারেটর | বাম থেকে ডান |
a>b a>=b a<b a<=b | রিলেশনাল অপারেটর | বাম থেকে ডান |
a in b | তালিকা বা মানচিত্রে অস্তিত্ব | বাম থেকে ডান |
type(a) == t | তুলনা টাইপ করুন, যেখানে t bool, int, float, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প বা সময়কাল হতে পারে | বাম থেকে ডান |
a==ba!=b | তুলনা অপারেটর | বাম থেকে ডান |
a && b | শর্তাধীন এবং | বাম থেকে ডান |
a || b | শর্তাধীন বা | বাম থেকে ডান |
a ? true_value : false_value | টার্নারি এক্সপ্রেশন | বাম থেকে ডান |
প্রমাণীকরণ টোকেনে ডেটা
auth.token
অবজেক্টে নিম্নলিখিত মান থাকতে পারে:
মাঠ | বর্ণনা |
---|---|
email | অ্যাকাউন্টের সাথে যুক্ত ইমেল ঠিকানা, যদি উপস্থিত থাকে। |
email_verified | true যদি ব্যবহারকারী যাচাই করে থাকে যে তাদের email ঠিকানায় অ্যাক্সেস আছে। কিছু প্রদানকারী স্বয়ংক্রিয়ভাবে তাদের মালিকানাধীন ইমেল ঠিকানা যাচাই করে। |
phone_number | অ্যাকাউন্টের সাথে যুক্ত ফোন নম্বর, যদি উপস্থিত থাকে। |
name | ব্যবহারকারীর প্রদর্শনের নাম, যদি সেট করা থাকে। |
sub | ব্যবহারকারীর Firebase UID. এটি একটি প্রকল্পের মধ্যে অনন্য। |
firebase.identities | এই ব্যবহারকারীর অ্যাকাউন্টের সাথে যুক্ত সমস্ত পরিচয়ের অভিধান। অভিধানের কীগুলি নিম্নলিখিতগুলির মধ্যে যেকোনো একটি হতে পারে: email , phone , google.com , facebook.com , github.com , twitter.com । অভিধানের মান হল অ্যাকাউন্টের সাথে যুক্ত প্রতিটি পরিচয় প্রদানকারীর জন্য অনন্য শনাক্তকারীর অ্যারে। উদাহরণস্বরূপ, auth.token.firebase.identities["google.com"][0] এ অ্যাকাউন্টের সাথে যুক্ত প্রথম Google ব্যবহারকারী আইডি রয়েছে৷ |
firebase.sign_in_provider | সাইন-ইন প্রদানকারী এই টোকেনটি পেতে ব্যবহৃত নিম্নলিখিত স্ট্রিংগুলির মধ্যে একটি হতে পারে: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com ৷ |
firebase.tenant | অ্যাকাউন্টের সাথে সংশ্লিষ্ট ভাড়াটে আইডি, যদি উপস্থিত থাকে। উদাহরণস্বরূপ, tenant2-m6tyz |
JWT আইডি টোকেনে অতিরিক্ত ক্ষেত্র
এছাড়াও আপনি নিম্নলিখিত auth.token
ক্ষেত্রগুলিতে অ্যাক্সেস করতে পারেন:
কাস্টম টোকেন দাবি | ||
---|---|---|
alg | অ্যালগরিদম | "RS256" |
iss | ইস্যুকারী | আপনার প্রকল্পের পরিষেবা অ্যাকাউন্ট ইমেল ঠিকানা |
sub | বিষয় | আপনার প্রকল্পের পরিষেবা অ্যাকাউন্ট ইমেল ঠিকানা |
aud | শ্রোতা | "https://identitytoolkit.googleapis.com/google.identity.identitytoolkit.v1.IdentityToolkit" |
iat | ইস্যু করা সময়ে | বর্তমান সময়, ইউনিক্স যুগের পর থেকে সেকেন্ডে |
exp | মেয়াদ শেষ হওয়ার সময় | সময়, UNIX যুগ থেকে সেকেন্ডে, যে সময়ে টোকেনের মেয়াদ শেষ হয়। এটি iat এর চেয়ে সর্বোচ্চ 3600 সেকেন্ড পরে হতে পারে।দ্রষ্টব্য: এটি শুধুমাত্র সেই সময়টিকে নিয়ন্ত্রণ করে যখন কাস্টম টোকেনের মেয়াদ শেষ হয়ে যায়। কিন্তু একবার আপনি signInWithCustomToken() ব্যবহার করে কোনো ব্যবহারকারীকে সাইন ইন করলে, তাদের সেশন বাতিল না হওয়া পর্যন্ত বা ব্যবহারকারী সাইন আউট না হওয়া পর্যন্ত তারা ডিভাইসে সাইন ইন থাকবে। |
<claims> (ঐচ্ছিক) | ঐচ্ছিক কাস্টম দাবি টোকেনে অন্তর্ভুক্ত করার জন্য, যা এক্সপ্রেশনে auth.token (বা request.auth.token ) এর মাধ্যমে অ্যাক্সেস করা যেতে পারে। উদাহরণস্বরূপ, আপনি যদি একটি কাস্টম দাবি adminClaim তৈরি করেন, আপনি auth.token.adminClaim এর মাধ্যমে এটি অ্যাক্সেস করতে পারেন। |
এরপর কি?
- Firebase Data Connect একটি অ্যাডমিন SDK প্রদান করে যাতে আপনি বিশেষ সুবিধাপ্রাপ্ত পরিবেশ থেকে প্রশ্ন এবং মিউটেশন করতে পারেন।
- পরিষেবা এবং ডাটাবেস পরিচালনার জন্য গাইডে IAM নিরাপত্তা সম্পর্কে জানুন।
Firebase Data Connect সাথে শক্তিশালী ক্লায়েন্ট-সাইড নিরাপত্তা প্রদান করে:
- মোবাইল এবং ওয়েব ক্লায়েন্ট অনুমোদন
- স্বতন্ত্র প্রশ্ন- এবং মিউটেশন-স্তরের অনুমোদন নিয়ন্ত্রণ
- Firebase App Check সহ অ্যাপ প্রত্যয়ন।
Data Connect এই নিরাপত্তা প্রসারিত করে:
- সার্ভার-সাইড অনুমোদন
- ফায়ারবেস প্রজেক্ট এবং ক্লাউড এসকিউএল ব্যবহারকারী নিরাপত্তা আইএএম-এর সাথে।
ক্লায়েন্ট প্রশ্ন এবং মিউটেশন অনুমোদন
Data Connect সম্পূর্ণরূপে Firebase Authentication সাথে একত্রিত, তাই আপনি সেই ব্যবহারকারীদের সম্পর্কে সমৃদ্ধ ডেটা ব্যবহার করতে পারেন যারা আপনার ডিজাইনে আপনার ডেটা (প্রমাণিকরণ) অ্যাক্সেস করছে সেই ব্যবহারকারীরা কোন ডেটা অ্যাক্সেস করতে পারে (অনুমোদন)।
Data Connect প্রশ্ন এবং মিউটেশনের জন্য একটি @auth
নির্দেশনা প্রদান করে যা আপনাকে অপারেশন অনুমোদন করার জন্য প্রয়োজনীয় প্রমাণীকরণের স্তর সেট করতে দেয়। এই নির্দেশিকাটি উদাহরণ সহ @auth
নির্দেশিকা প্রবর্তন করে ।
উপরন্তু, Data Connect মিউটেশনে এমবেড করা প্রশ্নগুলির সম্পাদনকে সমর্থন করে, তাই আপনি আপনার ডাটাবেসে সংরক্ষিত অতিরিক্ত অনুমোদনের মানদণ্ড পুনরুদ্ধার করতে পারেন, এবং এনক্লোসিং মিউটেশন অনুমোদিত কিনা তা সিদ্ধান্ত নিতে @check
নির্দেশাবলীতে সেই মানদণ্ডগুলি ব্যবহার করতে পারেন। এই অনুমোদনের ক্ষেত্রে, @redact
নির্দেশ আপনাকে ওয়্যার প্রোটোকলে ক্লায়েন্টদের কাছে কোয়েরির ফলাফল ফেরত দেওয়া হবে কিনা এবং জেনারেট করা SDK-এ এমবেডেড ক্যোয়ারী বাদ দেওয়া হবে কিনা তা নিয়ন্ত্রণ করতে দেয়। উদাহরণ সহ এই নির্দেশাবলীর ভূমিকা খুঁজুন।
@auth
নির্দেশ বুঝুন
আপনি অনেকগুলি সাধারণ অ্যাক্সেসের পরিস্থিতি কভার করে এমন কয়েকটি প্রিসেট অ্যাক্সেস লেভেলের একটি অনুসরণ করতে @auth
নির্দেশকে প্যারামিটারাইজ করতে পারেন। এই স্তরগুলি PUBLIC
(যা কোনো প্রকারের প্রমাণীকরণ ছাড়াই সমস্ত ক্লায়েন্টের কাছ থেকে প্রশ্ন এবং মিউটেশনের অনুমতি দেয়) থেকে NO_ACCESS
পর্যন্ত (যা ফায়ারবেস অ্যাডমিন SDK ব্যবহার করে বিশেষ সুবিধাপ্রাপ্ত সার্ভার পরিবেশের বাইরে প্রশ্ন এবং মিউটেশন অনুমোদন করে)। এই স্তরগুলির প্রতিটি Firebase Authentication দ্বারা প্রদত্ত প্রমাণীকরণ প্রবাহের সাথে সম্পর্কযুক্ত।
স্তর | সংজ্ঞা |
---|---|
PUBLIC | অপারেশনটি প্রমাণীকরণ সহ বা ছাড়াই যে কেউ সম্পাদন করতে পারে। |
PUBLIC | অপারেশনটি প্রমাণীকরণ সহ বা ছাড়াই যে কেউ সম্পাদন করতে পারে। |
USER_ANON | Firebase Authentication মাধ্যমে যারা বেনামে লগ ইন করেছেন তাদের সহ যেকোন চিহ্নিত ব্যবহারকারী, ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত। |
USER | যে কোনো ব্যবহারকারী যে Firebase Authentication মাধ্যমে লগ ইন করেছেন তারা বেনামী সাইন-ইন ব্যবহারকারীদের ছাড়া ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত। |
USER_EMAIL_VERIFIED | যে কোনো ব্যবহারকারী যিনি একটি যাচাইকৃত ইমেল ঠিকানা দিয়ে Firebase Authentication মাধ্যমে লগ ইন করেছেন তিনি ক্যোয়ারী বা মিউটেশন করার জন্য অনুমোদিত৷ |
NO_ACCESS | এই অপারেশনটি অ্যাডমিন SDK প্রসঙ্গের বাইরে চালানো যাবে না। |
প্রারম্ভিক বিন্দু হিসাবে এই প্রিসেট অ্যাক্সেস লেভেলগুলি ব্যবহার করে, আপনি সার্ভারে where
ফিল্টার এবং কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (CEL) এক্সপ্রেশনগুলি মূল্যায়ন করা হয় তা ব্যবহার করে @auth
নির্দেশে জটিল এবং শক্তিশালী অনুমোদন চেকগুলি সংজ্ঞায়িত করতে পারেন৷
সাধারণ অনুমোদনের পরিস্থিতি বাস্তবায়ন করতে @auth
নির্দেশিকা ব্যবহার করুন
প্রিসেট অ্যাক্সেস লেভেল হল অনুমোদনের সূচনা বিন্দু ।
USER
অ্যাক্সেস স্তরটি শুরু করার জন্য সবচেয়ে ব্যাপকভাবে দরকারী মৌলিক স্তর।
সম্পূর্ণ সুরক্ষিত অ্যাক্সেস USER
লেভেল প্লাস ফিল্টার এবং এক্সপ্রেশন তৈরি করবে যা ব্যবহারকারীর অ্যাট্রিবিউট, রিসোর্স অ্যাট্রিবিউট, ভূমিকা এবং অন্যান্য চেক চেক করে। USER_ANON
এবং USER_EMAIL_VERIFIED
স্তরগুলি হল USER
ক্ষেত্রের বিভিন্নতা৷
এক্সপ্রেশন সিনট্যাক্স আপনাকে একটি auth
অবজেক্ট ব্যবহার করে ডেটা মূল্যায়ন করতে দেয় যা অপারেশনের সাথে পাস করা প্রমাণীকরণ ডেটা উপস্থাপন করে, প্রমাণীকরণ টোকেনে স্ট্যান্ডার্ড ডেটা এবং টোকেনে কাস্টম ডেটা উভয়ই। auth
অবজেক্টে উপলব্ধ ক্ষেত্রগুলির তালিকার জন্য, রেফারেন্স বিভাগটি দেখুন।
অবশ্যই এমন কিছু ব্যবহার আছে যেখানে PUBLIC
হল সঠিক অ্যাক্সেস লেভেল দিয়ে শুরু করা। আবার, একটি অ্যাক্সেস স্তর সর্বদা একটি সূচনা বিন্দু, এবং শক্তিশালী নিরাপত্তার জন্য অতিরিক্ত ফিল্টার এবং অভিব্যক্তি প্রয়োজন।
এই নির্দেশিকাটি এখন USER
এবং PUBLIC
এ কীভাবে তৈরি করা যায় তার উদাহরণ দেয়৷
একটি প্রেরণাদায়ক উদাহরণ
নিম্নলিখিত সর্বোত্তম অনুশীলনের উদাহরণগুলি একটি পেমেন্ট প্ল্যানের পিছনে লক করা নির্দিষ্ট সামগ্রী সহ একটি ব্লগিং প্ল্যাটফর্মের জন্য নিম্নলিখিত স্কিমাকে উল্লেখ করে৷
এই ধরনের একটি প্ল্যাটফর্ম সম্ভবত Users
এবং Posts
মডেল হবে।
type User @table(key: "uid") {
uid: String!
name: String
birthday: Date
createdAt: Timestamp! @default(expr: "request.time")
}
type Post @table {
author: User!
text: String!
# "one of 'draft', 'public', or 'pro'"
visibility: String! @default(value: "draft")
# "the time at which the post should be considered published. defaults to
# immediately"
publishedAt: Timestamp! @default(expr: "request.time")
createdAt: Timestamp! @default(expr: "request.time")
updatedAt: Timestamp! @default(expr: "request.time")
}
ব্যবহারকারীর মালিকানাধীন সম্পদ
Firebase সুপারিশ করে যে আপনি এমন ফিল্টার এবং অভিব্যক্তি লিখুন যা একটি সংস্থানের ব্যবহারকারীর মালিকানা পরীক্ষা করে, নিম্নলিখিত ক্ষেত্রে, Posts
মালিকানা।
নিম্নলিখিত উদাহরণগুলিতে, প্রমাণীকরণ টোকেন থেকে ডেটা পড়া এবং এক্সপ্রেশন ব্যবহার করে তুলনা করা হয়। সাধারণ প্যাটার্ন হল where: {authorUid: {eq_expr: "auth.uid"}}
প্রমাণীকরণ টোকেনে পাস করা auth.uid
(ইউজার আইডি) এর সাথে একটি সংরক্ষিত authorUid
তুলনা করতে।
তৈরি করুন
এই অনুমোদনের অনুশীলনটি পরবর্তী অনুমোদন পরীক্ষায় তুলনা করার অনুমতি দেওয়ার জন্য প্রতিটি নতুন Post
একটি authorUid
ক্ষেত্র হিসাবে auth.uid
যোগ করার মাধ্যমে শুরু হয়।
# Create a new post as the current user
mutation CreatePost($text: String!, $visibility: String) @auth(level: USER) {
post_insert(data: {
# set the author's uid to the current user uid
authorUid_expr: "auth.uid"
text: $text
visibility: $visibility
})
}
আপডেট
যখন কোনো ক্লায়েন্ট কোনো Post
আপডেট করার চেষ্টা করে, আপনি সঞ্চিত authorUid
বিরুদ্ধে পাস করা auth.uid
পরীক্ষা করতে পারেন।
# Update one of the current user's posts
mutation UpdatePost($id: UUID!, $text: String, $visibility: String) @auth(level:USER) {
post_update(
# only update posts whose author is the current user
first: { where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}
}}
data: {
text: $text
visibility: $visibility
# insert the current server time for updatedAt
updatedAt_expr: "request.time"
}
)
}
মুছে দিন
একই কৌশল মুছে ফেলার ক্রিয়াকলাপ অনুমোদন করতে ব্যবহৃত হয়।
# Delete one of the current user's posts
mutation DeletePost($id: UUID!) @auth(level: USER) {
post_delete(
# only delete posts whose author is the current user
first: { where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}
}}
)
}
# Common display information for a post
fragment DisplayPost on Post {
id, text, createdAt, updatedAt
author { uid, name }
}
তালিকা
# List all posts belonging to the current user
query ListMyPosts @auth(level: USER) {
posts(where: {
userUid: {eq_expr: "auth.uid"}
}) {
# See the fragment above
...DisplayPost
# also show visibility since it is user-controlled
visibility
}
}
পান
# Get a post only if it belongs to the current user
query GetMyPost($id: UUID!) @auth(level: USER) {
post(key: {id: $id},
first: {where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}}
}}, {
# See the fragment above
...DisplayPost
# also show visibility since it is user-controlled
visibility
}
}
ফিল্টার ডেটা
Data Connect অনুমোদন ব্যবস্থা আপনাকে PUBLIC
মতো প্রিসেট অ্যাক্সেস লেভেলের পাশাপাশি প্রমাণীকরণ টোকেন থেকে ডেটা ব্যবহার করে অত্যাধুনিক ফিল্টার লিখতে দেয়।
অনুমোদন সিস্টেম আপনাকে শুধুমাত্র অভিব্যক্তি ব্যবহার করতে দেয়, বেস অ্যাক্সেস লেভেল ছাড়াই, যেমনটি নিম্নলিখিত কয়েকটি উদাহরণে দেখানো হয়েছে।
সম্পদ বৈশিষ্ট্য দ্বারা ফিল্টার
এখানে, অনুমোদন প্রমাণীকরণ টোকেনের উপর ভিত্তি করে নয় যেহেতু বেস নিরাপত্তা স্তরটি PUBLIC
এ সেট করা আছে৷ কিন্তু, আমরা সুস্পষ্টভাবে আমাদের ডাটাবেসে রেকর্ড সেট করতে পারি পাবলিক অ্যাক্সেসের জন্য উপযুক্ত হিসাবে; অনুমান করুন আমাদের ডাটাবেসে Post
রেকর্ড রয়েছে যার visibility
"পাবলিক" এ সেট করা আছে।
# List all posts marked as 'public' visibility
query ListPublicPosts @auth(level: PUBLIC) {
posts(where: {
# Test that visibility is "public"
visibility: {eq: "public"}
# Only display articles that are already published
publishedAt: {lt_expr: "request.time"}
}) {
# see the fragment above
...DisplayPost
}
}
ব্যবহারকারীর দাবি অনুযায়ী ফিল্টার করুন
এখানে, ধরে নিন আপনি কাস্টম ব্যবহারকারীর দাবিগুলি সেট আপ করেছেন যা প্রমাণীকরণ টোকেনে পাস করে আপনার অ্যাপের জন্য একটি "প্রো" প্ল্যানে ব্যবহারকারীদের সনাক্ত করার জন্য, প্রমাণীকরণ টোকেনে একটি auth.token.plan
ক্ষেত্রের সাথে পতাকাঙ্কিত। আপনার অভিব্যক্তি এই ক্ষেত্রের বিরুদ্ধে পরীক্ষা করতে পারেন.
# List all public or pro posts, only permitted if user has "pro" plan claim
query ProListPosts @auth(expr: "auth.token.plan == 'pro'") {
posts(where: {
# display both public posts and "pro" posts
visibility: {in: ['public', 'pro']},
# only display articles that are already published
publishedAt: {lt_expr: "request.time"},
}) {
# see the fragment above
...DisplayPost
# show visibility so pro users can see which posts are pro\
visibility
}
}
অর্ডার + সীমা অনুসারে ফিল্টার করুন
অথবা আবার, আপনি "প্রো" ব্যবহারকারীদের জন্য উপলব্ধ সামগ্রী সনাক্ত করতে Post
রেকর্ডগুলিতে visibility
সেট করতে পারেন, তবে ডেটার পূর্বরূপ বা টিজার তালিকার জন্য, ফেরত আসা রেকর্ডের সংখ্যা আরও সীমাবদ্ধ করুন৷
# Show 2 oldest Pro post as a preview
query ProTeaser @auth(level: USER) {
posts(
where: {
# show only pro posts
visibility: {eq: "pro"}
# that have already been published more than 30 days ago
publishedAt: {lt_time: {now: true, sub: {days: 30}}}
},
# order by publish time
orderBy: [{publishedAt: DESC}],
# only return two posts
limit: 2
) {
# See the fragment above
...DisplayPost
}
}
ভূমিকা দ্বারা ফিল্টার
যদি আপনার কাস্টম দাবি একটি admin
ভূমিকা সংজ্ঞায়িত করে, আপনি সেই অনুযায়ী অপারেশন পরীক্ষা এবং অনুমোদন করতে পারেন।
# List all posts unconditionally iff the current user has an admin claim
query AdminListPosts @auth(expr: "auth.token.admin == true") {
posts { ...DisplayPost }
}
@check
এবং @redact
নির্দেশাবলী বুঝুন
@check
নির্দেশিকা যাচাই করে যে নির্দিষ্ট ক্ষেত্রগুলি প্রশ্নের ফলাফলগুলিতে উপস্থিত রয়েছে৷ একটি কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিইএল) এক্সপ্রেশন ফিল্ডের মান পরীক্ষা করতে ব্যবহৃত হয়। নির্দেশের ডিফল্ট আচরণ হল null
-valued নোডগুলি পরীক্ষা করা এবং প্রত্যাখ্যান করা।
@redact
নির্দেশিকা ক্লায়েন্টের প্রতিক্রিয়ার একটি অংশকে সংশোধন করে। সংশোধিত ক্ষেত্রগুলি এখনও পার্শ্ব প্রতিক্রিয়াগুলির জন্য মূল্যায়ন করা হয় (ডেটা পরিবর্তন এবং @check
সহ) এবং ফলাফলগুলি এখনও CEL এক্সপ্রেশনের পরবর্তী ধাপগুলিতে উপলব্ধ।
Data Connect এ, @check
এবং @redact
নির্দেশাবলী প্রায়শই অনুমোদন চেকের প্রসঙ্গে ব্যবহৃত হয়; অনুমোদন ডেটা লুকআপের আলোচনা পড়ুন।
অনুমোদনের ডেটা দেখতে @check
চেক এবং @redact
নির্দেশিকা যোগ করুন
একটি সাধারণ অনুমোদন ব্যবহারের ক্ষেত্রে আপনার ডাটাবেসে কাস্টম অনুমোদনের ভূমিকাগুলি সংরক্ষণ করা জড়িত, উদাহরণস্বরূপ একটি বিশেষ অনুমতি সারণীতে, এবং ডেটা তৈরি, আপডেট বা মুছে ফেলার জন্য মিউটেশন অনুমোদন করতে সেই ভূমিকাগুলি ব্যবহার করে৷
অনুমোদন ডেটা লুকআপ ব্যবহার করে, আপনি একটি userID এর উপর ভিত্তি করে ভূমিকার জন্য অনুসন্ধান করতে পারেন এবং মিউটেশন অনুমোদিত কিনা তা নির্ধারণ করতে CEL এক্সপ্রেশন ব্যবহার করতে পারেন। উদাহরণস্বরূপ, আপনি একটি UpdateMovieTitle
মিউটেশন লিখতে চাইতে পারেন যা একটি অনুমোদিত ক্লায়েন্টকে মুভির শিরোনাম আপডেট করতে দেয়।
এই আলোচনার বাকি অংশের জন্য, ধরে নিন মুভি রিভিউ অ্যাপ ডাটাবেস একটি MoviePermission
টেবিলে একটি অনুমোদনের ভূমিকা সঞ্চয় করে।
# MoviePermission
# Suppose a user has an authorization role with respect to records in the Movie table
type MoviePermission @table(key: ["movie", "user"]) {
movie: Movie! # implies another field: movieId: UUID!
user: User!
role: String!
}
মিউটেশনে ব্যবহার করুন
নিম্নলিখিত উদাহরণ বাস্তবায়নে, UpdateMovieTitle
মিউটেশনে MoviePermission
থেকে ডেটা পুনরুদ্ধার করার জন্য একটি query
ক্ষেত্র রয়েছে এবং অপারেশনটি নিরাপদ এবং শক্তিশালী তা নিশ্চিত করার জন্য নিম্নলিখিত নির্দেশাবলী রয়েছে:
- সমস্ত অনুমোদনের প্রশ্ন এবং চেক সম্পূর্ণ হয়েছে বা পারমাণবিকভাবে ব্যর্থ হয়েছে তা নিশ্চিত করার জন্য একটি
@transaction
নির্দেশিকা। - প্রতিক্রিয়া থেকে প্রশ্নের ফলাফল বাদ দেওয়ার জন্য
@redact
নির্দেশিকা, যার অর্থ আমাদের অনুমোদনের পরীক্ষা Data Connect সার্ভারে সঞ্চালিত হয় কিন্তু সংবেদনশীল ডেটা ক্লায়েন্টের কাছে প্রকাশ করা হয় না। ক্যোয়ারী ফলাফলে অনুমোদনের যুক্তির মূল্যায়ন করার জন্য
@check
নির্দেশাবলীর এক জোড়া, যেমন পরীক্ষা করা যে প্রদত্ত ইউজারআইডি পরিবর্তন করার জন্য উপযুক্ত ভূমিকা রয়েছে।
mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query @redact {
moviePermission( # Look up a join table called MoviePermission with a compound key.
key: {movieId: $movieId, userId_expr: "auth.uid"}
# Step 1a: Use @check to test if the user has any role associated with the movie
# Here the `this` binding refers the lookup result, i.e. a MoviePermission object or null
# The `this != null` expression could be omitted since rejecting on null is default behavior
) @check(expr: "this != null", message: "You do not have access to this movie") {
# Step 1b: Check if the user has the editor role for the movie
# Next we execute another @check; now `this` refers to the contents of the `role` field
role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
প্রশ্নাবলী ব্যবহার করুন
ভূমিকা বা অন্যান্য বিধিনিষেধের উপর ভিত্তি করে প্রশ্নগুলিকে সীমাবদ্ধ করতে অনুমোদন ডেটা লুকআপগুলিও কার্যকর।
নিম্নলিখিত উদাহরণে, যেটি MoviePermission
স্কিমাও ব্যবহার করে, প্রশ্নটি পরীক্ষা করে যে একজন অনুরোধকারীর একটি উপযুক্ত "প্রশাসক" ভূমিকা আছে কিনা তা ব্যবহারকারীদের দেখার জন্য যারা একটি চলচ্চিত্র সম্পাদনা করতে পারে৷
query GetMovieEditors($movieId: UUID!) @auth(level: PUBLIC) {
moviePermission(key: { movieId: $movieId, userId_expr: "auth.uid" }) @redact {
role @check(expr: "this == 'admin'", message: "You must be an admin to view all editors of a movie.")
}
moviePermissions(where: { movieId: { eq: $movieId }, role: { eq: "editor" } }) {
user {
id
username
}
}
}
অনুমোদন এড়াতে অ্যান্টিপ্যাটার্নস
পূর্ববর্তী বিভাগে @auth
নির্দেশিকা ব্যবহার করার সময় অনুসরণ করা নিদর্শনগুলি কভার করে৷
এড়ানোর জন্য আপনার গুরুত্বপূর্ণ অ্যান্টিপ্যাটার্ন সম্পর্কেও সচেতন হওয়া উচিত।
ক্যোয়ারী এবং মিউটেশন আর্গুমেন্টে ব্যবহারকারীর অ্যাট্রিবিউট আইডি এবং প্রমাণীকরণ টোকেন প্যারামিটার পাস করা এড়িয়ে চলুন
Firebase Authentication হল প্রমাণীকরণের প্রবাহ উপস্থাপন করার জন্য এবং নিবন্ধিত ব্যবহারকারী আইডি এবং প্রমাণীকরণ টোকেনে সংরক্ষিত অসংখ্য ক্ষেত্রগুলির মতো প্রমাণীকরণ ডেটা সুরক্ষিতভাবে ক্যাপচার করার জন্য একটি শক্তিশালী টুল।
ক্যোয়ারী এবং মিউটেশন আর্গুমেন্টে ব্যবহারকারী আইডি এবং প্রমাণীকরণ টোকেন ডেটা পাস করার জন্য এটি একটি প্রস্তাবিত অনুশীলন নয়।
# Antipattern!
# This incorrectly allows any user to view any other user's posts
query AllMyPosts($userId: String!) @auth(level: USER) {
posts(where: {authorUid: {eq: $userId}}) {
id, text, createdAt
}
}
কোনো ফিল্টার ছাড়াই USER
অ্যাক্সেস লেভেল ব্যবহার করা এড়িয়ে চলুন
নির্দেশিকায় বেশ কয়েকবার আলোচনা করা হয়েছে, USER
, USER_ANON
, USER_EMAIL_VERIFIED
এর মত মূল অ্যাক্সেসের স্তরগুলি হল বেসলাইন এবং অনুমোদন চেকগুলির জন্য শুরুর পয়েন্ট, যা ফিল্টার এবং অভিব্যক্তিগুলির সাথে উন্নত করা যায়৷ সংশ্লিষ্ট ফিল্টার বা অভিব্যক্তি ছাড়াই এই স্তরগুলি ব্যবহার করা যা চেক করে যে কোন ব্যবহারকারী অনুরোধটি সম্পাদন করছে তা মূলত PUBLIC
স্তর ব্যবহার করার সমতুল্য৷
# Antipattern!
# This incorrectly allows any user to view all documents
query ListDocuments @auth(level: USER) {
documents {
id
title
text
}
}
প্রোটোটাইপিংয়ের জন্য PUBLIC
বা USER
অ্যাক্সেস লেভেল ব্যবহার করা এড়িয়ে চলুন
বিকাশের গতি বাড়ানোর জন্য, সমস্ত ক্রিয়াকলাপগুলিকে PUBLIC
অ্যাক্সেস লেভেলে বা USER
অ্যাক্সেস লেভেলে সেট করার জন্য প্রলুব্ধ হতে পারে যাতে সমস্ত ক্রিয়াকলাপ অনুমোদন করা যায় এবং আপনাকে দ্রুত আপনার কোড পরীক্ষা করতে দেয়৷
আপনি যখন এইভাবে খুব প্রাথমিক প্রোটোটাইপিং করেছেন, তখন NO_ACCESS
থেকে উত্পাদন-প্রস্তুত অনুমোদনের দিকে PUBLIC
এবং USER
স্তরের সাথে স্যুইচ করতে শুরু করুন। তবে এই গাইডটিতে প্রদর্শিত হিসাবে অতিরিক্ত যুক্তি যুক্ত না করে এগুলি PUBLIC
বা USER
হিসাবে স্থাপন করবেন না।
# Antipattern!
# This incorrectly allows anyone to delete any post
mutation DeletePost($id: UUID!) @auth(level: PUBLIC) {
post: post_delete(
id: $id,
)
}
অ্যাপ্লিকেশন সত্যতার জন্য Firebase App Check ব্যবহার করুন
প্রমাণীকরণ এবং অনুমোদন Data Connect সুরক্ষার সমালোচনামূলক উপাদান। অ্যাপ্লিকেশন প্রমাণের সাথে মিলিত প্রমাণীকরণ এবং অনুমোদন খুব শক্তিশালী সুরক্ষা সমাধানের জন্য তৈরি করে।
Firebase App Check মাধ্যমে সত্যতা সহ, আপনার অ্যাপ্লিকেশনটি চালিত ডিভাইসগুলি একটি অ্যাপ্লিকেশন বা ডিভাইস সত্যতা সরবরাহকারী ব্যবহার করবে যা প্রমাণ করে যে Data Connect অপারেশনগুলি আপনার খাঁটি অ্যাপ্লিকেশন থেকে উদ্ভূত হয় এবং অনুরোধগুলি একটি খাঁটি, অনাবৃত ডিভাইস থেকে উদ্ভূত হয়। এই সত্যতাটি আপনার অ্যাপ্লিকেশনটি Data Connect করে প্রতিটি অনুরোধের সাথে সংযুক্ত থাকে।
Data Connect জন্য কীভাবে App Check সক্ষম করতে এবং আপনার অ্যাপ্লিকেশনটিতে এর ক্লায়েন্ট এসডিকে অন্তর্ভুক্ত করতে পারে তা শিখতে, App Check ওভারভিউটি দেখুন ।
@auth(level)
নির্দেশকের জন্য প্রমাণীকরণ স্তর
নিম্নলিখিত টেবিলটি সমস্ত স্ট্যান্ডার্ড অ্যাক্সেস স্তর এবং তাদের সিইএল সমতুল্য তালিকাভুক্ত করে। প্রমাণীকরণের স্তরগুলি বিস্তৃত থেকে সংকীর্ণ পর্যন্ত তালিকাভুক্ত করা হয় - প্রতিটি স্তর নিম্নলিখিত স্তরের সাথে মেলে এমন সমস্ত ব্যবহারকারীকে অন্তর্ভুক্ত করে।
স্তর | সংজ্ঞা |
---|---|
PUBLIC | অপারেশনটি প্রমাণীকরণের সাথে বা ছাড়াই যে কেউ দ্বারা সম্পাদন করা যেতে পারে। বিবেচনাগুলি: ডেটা কোনও ব্যবহারকারী দ্বারা পড়া বা সংশোধন করা যেতে পারে। ফায়ারবেস পণ্য বা মিডিয়া তালিকার মতো সর্বজনীন-ব্রাউজযোগ্য ডেটার জন্য এই স্তরের অনুমোদনের পরামর্শ দেয়। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন। @auth(expr: "true") @auth ফিল্টার এবং এক্সপ্রেশনগুলি এই অ্যাক্সেস স্তরের সাথে একত্রে ব্যবহার করা যাবে না। এই জাতীয় কোনও অভিব্যক্তি 400 টি খারাপ অনুরোধ ত্রুটির সাথে ব্যর্থ হবে। |
USER_ANON | যারা Firebase Authentication সাথে বেনামে লগ ইন করেছেন তাদের সহ যে কোনও চিহ্নিত ব্যবহারকারী ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। দ্রষ্টব্য: USER_ANON USER একটি সুপারসেট।বিবেচনাগুলি: নোট করুন যে অনুমোদনের এই স্তরের জন্য আপনাকে অবশ্যই আপনার প্রশ্ন এবং মিউটেশনগুলি সাবধানতার সাথে ডিজাইন করতে হবে। এই স্তরটি Authentication সাথে ব্যবহারকারীকে বেনামে (কেবলমাত্র কোনও ব্যবহারকারী ডিভাইসে আবদ্ধ স্বয়ংক্রিয় সাইন-ইন বেঁধে) লগ ইন করার অনুমতি দেয় এবং নিজের নিজস্ব চেকগুলি সম্পাদন করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্ভুক্ত কিনা। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন। যেহেতু Authentication বেনামে লগইন প্রবাহিত একটি uid ইস্যু করে, তাই USER_ANON স্তরটি সমতুল্য@auth(expr: "auth.uid != nil") |
USER | যে কোনও ব্যবহারকারী যিনি Firebase Authentication সাথে লগ ইন করেছেন তাকে বেনামে সাইন-ইন ব্যবহারকারীদের ব্যতীত ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। বিবেচনাগুলি: নোট করুন যে অনুমোদনের এই স্তরের জন্য আপনাকে অবশ্যই আপনার প্রশ্ন এবং মিউটেশনগুলি সাবধানতার সাথে ডিজাইন করতে হবে। এই স্তরটি কেবল চেক করে যে ব্যবহারকারী Authentication সাথে লগ ইন করেছেন, এবং নিজের নিজের উপর অন্য চেকগুলি সম্পাদন করেন না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন। @auth(expr: "auth.uid != nil && auth.token.firebase.sign_in_provider != 'anonymous'")" |
USER_EMAIL_VERIFIED | যে কোনও ব্যবহারকারী যিনি একটি যাচাই করা ইমেল ঠিকানা সহ Firebase Authentication সাথে লগ ইন করেছেন তাদের ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। বিবেচনাগুলি: যেহেতু ইমেল যাচাইকরণ Authentication ব্যবহার করে সঞ্চালিত হয়, এটি আরও শক্তিশালী Authentication পদ্ধতির উপর ভিত্তি করে, সুতরাং এই স্তরটি USER বা USER_ANON তুলনায় অতিরিক্ত সুরক্ষা সরবরাহ করে। এই স্তরটি কেবল চেক করে যে ব্যবহারকারী একটি যাচাই করা ইমেলের সাথে Authentication সাথে লগ ইন করেছেন এবং এটি নিজস্বভাবে অন্য চেকগুলি সম্পাদন করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন।@auth(expr: "auth.uid != nil && auth.token.email_verified")" |
NO_ACCESS | এই অপারেশনটি কোনও অ্যাডমিন এসডিকে প্রসঙ্গে কার্যকর করা যায় না।@auth(expr: "false") |
@auth(expr)
এবং @check(expr)
এর জন্য সেল রেফারেন্স
এই গাইডের অন্য কোথাও উদাহরণগুলিতে দেখানো হয়েছে, আপনি @auth(expr:)
এবং @check
নির্দেশাবলী ব্যবহার করে Data Connect জন্য অনুমোদন নিয়ন্ত্রণ করতে সাধারণ এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিএল) এ সংজ্ঞায়িত এক্সপ্রেশনগুলি ব্যবহার করতে পারেন এবং ব্যবহার করতে পারেন।
এই বিভাগটি এই নির্দেশাবলীর জন্য অভিব্যক্তি তৈরির জন্য প্রাসঙ্গিক সিইএল সিনট্যাক্সকে কভার করে।
সিইএল এর জন্য সম্পূর্ণ রেফারেন্স তথ্য সিইএল স্পেসিফিকেশনে সরবরাহ করা হয়।
পরীক্ষার ভেরিয়েবলগুলি প্রশ্ন এবং মিউটেশনে পাস করেছে
@auth(expr)
সিনট্যাক্স আপনাকে কোয়েরি এবং মিউটেশনগুলি থেকে ভেরিয়েবলগুলি অ্যাক্সেস এবং পরীক্ষার অনুমতি দেয়।
উদাহরণস্বরূপ, আপনি vars.status
ব্যবহার করে একটি অপারেশন ভেরিয়েবল যেমন $status
অন্তর্ভুক্ত করতে পারেন।
mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")
এক্সপ্রেশনগুলিতে ডেটা উপলব্ধ
উভয়ই @auth(expr:)
এবং @check(expr:)
সেল এক্সপ্রেশনগুলি নিম্নলিখিতগুলি মূল্যায়ন করতে পারে:
-
request.operationName
-
vars
(request.variables
জন্য ওরফে। ভেরিয়েবলস) -
auth
(request.auth
জন্য ওরফে।
অতিরিক্তভাবে, @check(expr:)
এক্সপ্রেশনগুলি মূল্যায়ন করতে পারে:
-
this
(বর্তমান ক্ষেত্রের মান)
অনুরোধ.অপ্রেশন নাম অবজেক্ট
request.operarationName
নাম অবজেক্টটি অপারেশনের ধরণটি সঞ্চয় করে, ক্যোয়ারী বা মিউটেশন হয়।
vars
অবজেক্ট
vars
অবজেক্টটি আপনার এক্সপ্রেশনগুলিকে আপনার ক্যোয়ারী বা মিউটেশনে পাস করা সমস্ত ভেরিয়েবলগুলি অ্যাক্সেস করতে দেয়।
আপনি সম্পূর্ণরূপে যোগ্যতার request.variables.<variablename>
জন্য একটি উপন্যাস হিসাবে একটি অভিব্যক্তিতে vars.<variablename>
ব্যবহার করতে পারেন <ভেরিব্লেনাম>।
# The following are equivalent
mutation StringType($v: String!) @auth(expr: "vars.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")
auth
অবজেক্ট
Authentication ব্যবহারকারীদের আপনার ডেটাতে অ্যাক্সেসের জন্য অনুরোধ করে সনাক্ত করে এবং সেই তথ্যটি এমন একটি বস্তু হিসাবে সরবরাহ করে যা আপনি আপনার অভিব্যক্তিগুলিতে তৈরি করতে পারেন।
আপনার ফিল্টার এবং এক্সপ্রেশনগুলিতে, আপনি request.auth
জন্য একটি নাম হিসাবে auth
ব্যবহার করতে পারেন a
লেখক অবজেক্টে নিম্নলিখিত তথ্য রয়েছে:
-
uid
: একটি অনন্য ব্যবহারকারী আইডি, অনুরোধকারী ব্যবহারকারীকে বরাদ্দ করা হয়েছে। -
token
: Authentication দ্বারা সংগৃহীত মানগুলির একটি মানচিত্র।
auth.token
এর অবিচ্ছিন্ন সম্পর্কে আরও তথ্যের জন্য আথ টোকেনগুলিতে ডেটা দেখুন
this
বাঁধাই
this
বাঁধাই এই ক্ষেত্রের সাথে মূল্যায়ন করে যা @check
নির্দেশিকাটি সংযুক্ত রয়েছে। একটি প্রাথমিক ক্ষেত্রে, আপনি একক মূল্যবান ক্যোয়ারী ফলাফল মূল্যায়ন করতে পারেন।
mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query @redact {
moviePermission( # Look up a join table called MoviePermission with a compound key.
key: {movieId: $movieId, userId_expr: "auth.uid"}
) {
# Check if the user has the editor role for the movie. `this` is the string value of `role`.
# If the parent moviePermission is null, the @check will also fail automatically.
role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
যদি ফেরত ক্ষেত্রটি একাধিকবার ঘটে কারণ যে কোনও পূর্বপুরুষ একটি তালিকা, প্রতিটি ঘটনা প্রতিটি মানের সাথে this
আবদ্ধ দিয়ে পরীক্ষা করা হয়।
যে কোনও প্রদত্ত পথের জন্য, যদি কোনও পূর্বপুরুষ null
বা []
হয় তবে ক্ষেত্রটি পৌঁছে যাবে না এবং সেল মূল্যায়ন সেই পথে এড়িয়ে যাবে। অন্য কথায়, মূল্যায়ন কেবল তখনই ঘটে যখন this
null
বা অ- null
হয়, তবে কখনই undefined
না।
যখন ক্ষেত্রটি নিজেই একটি তালিকা বা অবজেক্ট হয়, this
একই কাঠামো অনুসরণ করে (অবজেক্টের ক্ষেত্রে নির্বাচিত সমস্ত সিদ্ধান্ত সহ), নিম্নলিখিত উদাহরণে চিত্রিত হিসাবে।
mutation UpdateMovieTitle2($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query {
moviePermissions( # Now we query for a list of all matching MoviePermissions.
where: {movieId: {eq: $movieId}, userId: {eq_expr: "auth.uid"}}
# This time we execute the @check on the list, so `this` is the list of objects.
# We can use the `.exists` macro to check if there is at least one matching entry.
) @check(expr: "this.exists(p, p.role == 'editor')", message: "You must be an editor of this movie to update title") {
role
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
জটিল এক্সপ্রেশন সিনট্যাক্স
আপনি &&
এর সাথে একত্রিত হয়ে আরও জটিল অভিব্যক্তি লিখতে পারেন এবং ||
অপারেটর
mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (vars.username == 'joe')")
নিম্নলিখিত বিভাগটি সমস্ত উপলভ্য অপারেটর বর্ণনা করে।
অপারেটর এবং অপারেটর অগ্রাধিকার
অপারেটর এবং তাদের সম্পর্কিত অগ্রাধিকারের জন্য একটি রেফারেন্স হিসাবে নিম্নলিখিত টেবিলটি ব্যবহার করুন।
নির্বিচারে অভিব্যক্তি a
এবং b
, একটি ক্ষেত্র f
এবং একটি সূচক i
।
অপারেটর | বর্ণনা | সহযোগীতা |
---|---|---|
a[i] a() af | সূচক, কল, ক্ষেত্র অ্যাক্সেস | বাম থেকে ডান |
!a -a | ইউনারি নেগেটিভ | ডান থেকে বাম |
a/ba%ba*b | মাল্টিপ্লেটিভ অপারেটর | বাম থেকে ডান |
a+b ab | সংযোজন অপারেটর | বাম থেকে ডান |
a>b a>=b a<b a<=b | রিলেশনাল অপারেটর | বাম থেকে ডান |
a in b | তালিকা বা মানচিত্রে অস্তিত্ব | বাম থেকে ডান |
type(a) == t | তুলনা টাইপ করুন, যেখানে t বুল, ইনট, ফ্লোট, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প বা সময়কাল হতে পারে | বাম থেকে ডান |
a==ba!=b | তুলনা অপারেটর | বাম থেকে ডান |
a && b | শর্তাধীন এবং | বাম থেকে ডান |
a || b | শর্তাধীন বা | বাম থেকে ডান |
a ? true_value : false_value | টেরিনারি এক্সপ্রেশন | বাম থেকে ডান |
অ্যাথ টোকেনগুলিতে ডেটা
auth.token
অবজেক্টে নিম্নলিখিত মানগুলি থাকতে পারে:
মাঠ | বর্ণনা |
---|---|
email | অ্যাকাউন্টের সাথে সম্পর্কিত ইমেল ঠিকানা, উপস্থিত থাকলে। |
email_verified | true যদি ব্যবহারকারী যাচাই করে থাকেন তবে তাদের email ঠিকানায় অ্যাক্সেস রয়েছে। কিছু সরবরাহকারী স্বয়ংক্রিয়ভাবে তাদের নিজস্ব ইমেল ঠিকানাগুলি যাচাই করে। |
phone_number | অ্যাকাউন্টের সাথে যুক্ত ফোন নম্বর, উপস্থিত থাকলে। |
name | ব্যবহারকারীর প্রদর্শনের নাম, যদি সেট করা হয়। |
sub | ব্যবহারকারীর ফায়ারবেস ইউআইডি। এটি একটি প্রকল্পের মধ্যে অনন্য। |
firebase.identities | এই ব্যবহারকারীর অ্যাকাউন্টের সাথে সম্পর্কিত সমস্ত পরিচয়ের অভিধান। অভিধানের কীগুলি নিম্নলিখিতগুলির মধ্যে যে কোনও হতে পারে: email , phone , google.com , facebook.com , github.com , twitter.com । অভিধানের মানগুলি অ্যাকাউন্টের সাথে সম্পর্কিত প্রতিটি পরিচয় সরবরাহকারীর জন্য অনন্য শনাক্তকারীদের অ্যারে। উদাহরণস্বরূপ, auth.token.firebase.identities["google.com"][0] অ্যাকাউন্টের সাথে সম্পর্কিত প্রথম গুগল ব্যবহারকারী আইডি রয়েছে। |
firebase.sign_in_provider | সাইন-ইন সরবরাহকারী এই টোকেনটি পেতে ব্যবহৃত হত। নিম্নলিখিত স্ট্রিংগুলির মধ্যে একটি হতে পারে: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com । |
firebase.tenant | অ্যাকাউন্টের সাথে যুক্ত টেনানটিড, উপস্থিত থাকলে। উদাহরণস্বরূপ, tenant2-m6tyz |
জেডব্লিউটি আইডি টোকেনগুলিতে অতিরিক্ত ক্ষেত্র
আপনি নিম্নলিখিত auth.token
ক্ষেত্রগুলিও অ্যাক্সেস করতে পারেন:
কাস্টম টোকেন দাবি | ||
---|---|---|
alg | অ্যালগরিদম | "RS256" |
iss | ইস্যুকারী | আপনার প্রকল্পের পরিষেবা অ্যাকাউন্ট ইমেল ঠিকানা |
sub | বিষয় | আপনার প্রকল্পের পরিষেবা অ্যাকাউন্ট ইমেল ঠিকানা |
aud | শ্রোতা | "https://identitytoolkit.googleapis.com/google.identity.identitytoolkit.v1.IdentityToolkit" |
iat | জারি-সময় | বর্তমান সময়, ইউনিক্স যুগের পরে কয়েক সেকেন্ডে |
exp | মেয়াদ শেষ হওয়ার সময় | সময়, ইউনিক্স যুগের পরে কয়েক সেকেন্ডের মধ্যে, যেখানে টোকেনের মেয়াদ শেষ হয়। এটি iat চেয়ে সর্বোচ্চ 3600 সেকেন্ড পরে হতে পারে।দ্রষ্টব্য: এটি কেবল সেই সময়টিকে নিয়ন্ত্রণ করে যখন কাস্টম টোকেন নিজেই মেয়াদ শেষ হয়। তবে একবার আপনি কোনও ব্যবহারকারীকে signInWithCustomToken() ব্যবহার করতে স্বাক্ষর করলে তারা তাদের সেশনটি অবৈধ না হওয়া বা ব্যবহারকারী সাইন আউট না হওয়া পর্যন্ত তারা ডিভাইসে সাইন ইন থাকবে। |
<claims> (al চ্ছিক) | Oke চ্ছিক কাস্টম দাবিগুলি টোকেনে অন্তর্ভুক্ত করার দাবি করে, যা এক্সপ্রেশনগুলিতে auth.token (বা request.auth.token ) এর মাধ্যমে অ্যাক্সেস করা যায়। উদাহরণস্বরূপ, আপনি যদি একটি কাস্টম দাবি adminClaim তৈরি করেন তবে আপনি এটি auth.token.adminClaim দিয়ে অ্যাক্সেস করতে পারেন। |
এরপর কি?
- Firebase Data Connect আপনাকে সুবিধাযুক্ত পরিবেশ থেকে প্রশ্ন এবং মিউটেশনগুলি সম্পাদন করতে একটি অ্যাডমিন এসডিকে সরবরাহ করে।
- পরিষেবা এবং ডাটাবেস পরিচালনার জন্য গাইডে আইএএম সুরক্ষা সম্পর্কে জানুন।
Firebase Data Connect সাথে শক্তিশালী ক্লায়েন্ট-সাইড সুরক্ষা সরবরাহ করে:
- মোবাইল এবং ওয়েব ক্লায়েন্ট অনুমোদন
- স্বতন্ত্র ক্যোয়ারী- এবং মিউটেশন-স্তরের অনুমোদন নিয়ন্ত্রণ
- Firebase App Check সহ অ্যাপ্লিকেশন প্রমাণীকরণ।
Data Connect এই সুরক্ষা সহ প্রসারিত করে:
- সার্ভার-সাইড অনুমোদন
- আইএএম সহ ফায়ারবেস প্রকল্প এবং ক্লাউড এসকিউএল ব্যবহারকারী সুরক্ষা।
ক্লায়েন্ট অনুসন্ধান এবং মিউটেশন অনুমোদন
Data Connect Firebase Authentication সাথে সম্পূর্ণ সংহত করা হয়েছে, যাতে আপনি ব্যবহারকারীরা কী ডেটা অ্যাক্সেস করতে পারবেন (অনুমোদন) এর জন্য আপনার ডিজাইনে আপনার ডেটা (প্রমাণীকরণ) অ্যাক্সেস করছেন এমন ব্যবহারকারীদের সম্পর্কে সমৃদ্ধ ডেটা ব্যবহার করতে পারেন।
Data Connect প্রশ্ন এবং মিউটেশনের জন্য একটি @auth
নির্দেশিকা সরবরাহ করে যা আপনাকে অপারেশন অনুমোদনের জন্য প্রয়োজনীয় প্রমাণীকরণের স্তরটি সেট করতে দেয়। এই গাইডটি উদাহরণ সহ @auth
নির্দেশিকাটির সাথে পরিচয় করিয়ে দেয় ।
তদতিরিক্ত, Data Connect মিউটেশনগুলিতে এম্বেড থাকা প্রশ্নের কার্যকরকরণকে সমর্থন করে, যাতে আপনি আপনার ডাটাবেসে সংরক্ষণ করেছেন অতিরিক্ত অনুমোদনের মানদণ্ড পুনরুদ্ধার করতে পারেন এবং ঘেরে থাকা মিউটেশনগুলি অনুমোদিত কিনা তা সিদ্ধান্ত নিতে @check
নির্দেশিকায় সেই মানদণ্ডগুলি ব্যবহার করতে পারেন। এই অনুমোদনের ক্ষেত্রে, @redact
নির্দেশিকা আপনাকে তারের প্রোটোকল এবং এম্বেড থাকা ক্যোয়ারী উত্পন্ন এসডিকেগুলিতে বাদ দেওয়া ক্যোয়ারির ফলাফলগুলি ফিরিয়ে দেওয়া হয়েছে কিনা তা নিয়ন্ত্রণ করতে দেয়। উদাহরণ সহ এই নির্দেশাবলীর পরিচিতি সন্ধান করুন।
@auth
নির্দেশিকাটি বুঝতে
আপনি অনেকগুলি প্রিসেট অ্যাক্সেস স্তরের একটি অনুসরণ করতে @auth
নির্দেশকে প্যারামিটারাইজ করতে পারেন যা অনেকগুলি সাধারণ অ্যাক্সেসের পরিস্থিতি কভার করে। এই স্তরগুলি PUBLIC
থেকে শুরু করে (যা কোনও প্রকারের প্রমাণীকরণ ছাড়াই সমস্ত ক্লায়েন্টের কাছ থেকে প্রশ্ন এবং মিউটেশনগুলির অনুমতি দেয়) NO_ACCESS
(যা ফায়ারবেস অ্যাডমিন এসডিকে ব্যবহার করে সুবিধাযুক্ত সার্ভার পরিবেশের বাইরে প্রশ্ন এবং রূপান্তরগুলি অস্বীকার করে) পর্যন্ত। এই স্তরগুলির প্রতিটি Firebase Authentication দ্বারা সরবরাহিত প্রমাণীকরণ প্রবাহের সাথে সম্পর্কিত।
স্তর | সংজ্ঞা |
---|---|
PUBLIC | অপারেশনটি প্রমাণীকরণের সাথে বা ছাড়াই যে কেউ দ্বারা সম্পাদন করা যেতে পারে। |
PUBLIC | অপারেশনটি প্রমাণীকরণের সাথে বা ছাড়াই যে কেউ দ্বারা সম্পাদন করা যেতে পারে। |
USER_ANON | যারা Firebase Authentication সাথে বেনামে লগ ইন করেছেন তাদের সহ যে কোনও চিহ্নিত ব্যবহারকারী ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। |
USER | যে কোনও ব্যবহারকারী যিনি Firebase Authentication সাথে লগ ইন করেছেন তাকে বেনামে সাইন-ইন ব্যবহারকারীদের ব্যতীত ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। |
USER_EMAIL_VERIFIED | যে কোনও ব্যবহারকারী যিনি একটি যাচাই করা ইমেল ঠিকানা সহ Firebase Authentication সাথে লগ ইন করেছেন তাদের ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। |
NO_ACCESS | এই অপারেশনটি কোনও অ্যাডমিন এসডিকে প্রসঙ্গে কার্যকর করা যায় না। |
এই প্রিসেট অ্যাক্সেস স্তরগুলি একটি প্রারম্ভিক পয়েন্ট হিসাবে ব্যবহার করে, আপনি সার্ভারে ফিল্টার এবং সাধারণ এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিএল) এক্সপ্রেশনগুলি where
মূল্যায়ন করেছেন সেখানে ব্যবহার করে @auth
ডাইরেক্টিভে জটিল এবং দৃ ust ় অনুমোদনের চেকগুলি সংজ্ঞায়িত করতে পারেন।
সাধারণ অনুমোদনের পরিস্থিতি বাস্তবায়নের জন্য @auth
নির্দেশিকাটি ব্যবহার করুন
প্রিসেট অ্যাক্সেস স্তরগুলি অনুমোদনের সূচনা পয়েন্ট ।
USER
অ্যাক্সেস স্তরটি শুরু করার জন্য সর্বাধিক ব্যাপকভাবে দরকারী বেসিক স্তর।
সম্পূর্ণরূপে সুরক্ষিত অ্যাক্সেস USER
স্তর এবং ফিল্টার এবং এক্সপ্রেশনগুলিতে তৈরি করবে যা ব্যবহারকারীর বৈশিষ্ট্য, সংস্থান বৈশিষ্ট্য, ভূমিকা এবং অন্যান্য চেকগুলি পরীক্ষা করে। USER_ANON
এবং USER_EMAIL_VERIFIED
স্তরগুলি USER
ক্ষেত্রে বিভিন্নতা।
এক্সপ্রেশন সিনট্যাক্স আপনাকে অপারেশনগুলির সাথে পাস করা প্রমাণীকরণের ডেটা উপস্থাপন করে এমন কোনও auth
অবজেক্ট ব্যবহার করে ডেটা মূল্যায়ন করতে দেয়, উভয়ই আথ টোকেনের স্ট্যান্ডার্ড ডেটা এবং টোকেনগুলিতে কাস্টম ডেটা উভয়ই। auth
অবজেক্টে উপলব্ধ ক্ষেত্রগুলির তালিকার জন্য, রেফারেন্স বিভাগটি দেখুন।
অবশ্যই ব্যবহারের ক্ষেত্রে রয়েছে যেখানে PUBLIC
সাথে সঠিক অ্যাক্সেস স্তর শুরু হয়। আবার, একটি অ্যাক্সেস স্তর সর্বদা একটি সূচনা পয়েন্ট এবং শক্তিশালী সুরক্ষার জন্য অতিরিক্ত ফিল্টার এবং এক্সপ্রেশন প্রয়োজন।
এই গাইডটি এখন USER
এবং PUBLIC
উপর কীভাবে তৈরি করা যায় তার উদাহরণ দেয়।
একটি প্রেরণাদায়ক উদাহরণ
নিম্নলিখিত সেরা অনুশীলনের উদাহরণগুলি একটি ব্লগিং প্ল্যাটফর্মের জন্য নিম্নলিখিত স্কিমা উল্লেখ করে যা নির্দিষ্ট সামগ্রীর সাথে অর্থ প্রদানের পরিকল্পনার পিছনে লক থাকে।
এই জাতীয় প্ল্যাটফর্ম সম্ভবত Users
এবং Posts
মডেল করবে।
type User @table(key: "uid") {
uid: String!
name: String
birthday: Date
createdAt: Timestamp! @default(expr: "request.time")
}
type Post @table {
author: User!
text: String!
# "one of 'draft', 'public', or 'pro'"
visibility: String! @default(value: "draft")
# "the time at which the post should be considered published. defaults to
# immediately"
publishedAt: Timestamp! @default(expr: "request.time")
createdAt: Timestamp! @default(expr: "request.time")
updatedAt: Timestamp! @default(expr: "request.time")
}
ব্যবহারকারীর মালিকানাধীন সংস্থান
ফায়ারবেস সুপারিশ করে যে আপনি ফিল্টার এবং এক্সপ্রেশন লিখুন যা কোনও সংস্থার ব্যবহারকারীর মালিকানা পরীক্ষা করে, নিম্নলিখিত ক্ষেত্রে, Posts
মালিকানা।
নিম্নলিখিত উদাহরণগুলিতে, অ্যাথ টোকেনগুলির ডেটাগুলি এক্সপ্রেশনগুলি ব্যবহার করে পড়া এবং তুলনা করা হয়। সাধারণ প্যাটার্নটি হ'ল where: {authorUid: {eq_expr: "auth.uid"}}
যেমন প্রমাণীকরণ টোকেনে পাস করা auth.uid
(ব্যবহারকারী আইডি) এর সাথে সঞ্চিত authorUid
তুলনা করতে।
তৈরি করুন
এই অনুমোদনের অনুশীলনটি পরবর্তী authorUid
অনুমোদনের পরীক্ষায় তুলনা করার অনুমতি দেওয়ার জন্য একটি নতুন পোস্টে Auth টোকেন থেকে প্রতিটি নতুন Post
auth.uid
যুক্ত করে শুরু হয়।
# Create a new post as the current user
mutation CreatePost($text: String!, $visibility: String) @auth(level: USER) {
post_insert(data: {
# set the author's uid to the current user uid
authorUid_expr: "auth.uid"
text: $text
visibility: $visibility
})
}
আপডেট
যখন কোনও ক্লায়েন্ট কোনও Post
আপডেট করার চেষ্টা করে, আপনি সঞ্চিত authorUid
বিপরীতে পাস করা auth.uid
পরীক্ষা করতে পারেন।
# Update one of the current user's posts
mutation UpdatePost($id: UUID!, $text: String, $visibility: String) @auth(level:USER) {
post_update(
# only update posts whose author is the current user
first: { where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}
}}
data: {
text: $text
visibility: $visibility
# insert the current server time for updatedAt
updatedAt_expr: "request.time"
}
)
}
মুছে দিন
একই কৌশলটি মুছুন অপারেশনগুলি অনুমোদনের জন্য ব্যবহৃত হয়।
# Delete one of the current user's posts
mutation DeletePost($id: UUID!) @auth(level: USER) {
post_delete(
# only delete posts whose author is the current user
first: { where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}
}}
)
}
# Common display information for a post
fragment DisplayPost on Post {
id, text, createdAt, updatedAt
author { uid, name }
}
তালিকা
# List all posts belonging to the current user
query ListMyPosts @auth(level: USER) {
posts(where: {
userUid: {eq_expr: "auth.uid"}
}) {
# See the fragment above
...DisplayPost
# also show visibility since it is user-controlled
visibility
}
}
পান
# Get a post only if it belongs to the current user
query GetMyPost($id: UUID!) @auth(level: USER) {
post(key: {id: $id},
first: {where: {
id: {eq: $id}
authorUid: {eq_expr: "auth.uid"}}
}}, {
# See the fragment above
...DisplayPost
# also show visibility since it is user-controlled
visibility
}
}
ফিল্টার ডেটা
Data Connect অনুমোদনের সিস্টেম আপনাকে PUBLIC
মতো প্রিসেট অ্যাক্সেস স্তরের সাথে সংযুক্ত পাশাপাশি অ্যাথ টোকেনগুলির ডেটা ব্যবহার করে পরিশীলিত ফিল্টারগুলি লিখতে দেয়।
অনুমোদনের সিস্টেমটি আপনাকে কেবল বেস অ্যাক্সেস স্তর ছাড়াই কেবল এক্সপ্রেশনগুলি ব্যবহার করতে দেয়, যেমন নিম্নলিখিত কয়েকটি উদাহরণে দেখানো হয়েছে।
রিসোর্স বৈশিষ্ট্য দ্বারা ফিল্টার
এখানে, বেস সুরক্ষা স্তরটি PUBLIC
সেট করা হওয়ায় অনুমোদন অ্যাথ টোকেনের উপর ভিত্তি করে নয়। তবে, আমরা জনসাধারণের অ্যাক্সেসের জন্য উপযুক্ত হিসাবে আমাদের ডাটাবেসে স্পষ্টভাবে রেকর্ড সেট করতে পারি; ধরে নিন আমাদের ডাটাবেসে Post
রেকর্ড রয়েছে যা visibility
"পাবলিক" তে সেট করে।
# List all posts marked as 'public' visibility
query ListPublicPosts @auth(level: PUBLIC) {
posts(where: {
# Test that visibility is "public"
visibility: {eq: "public"}
# Only display articles that are already published
publishedAt: {lt_expr: "request.time"}
}) {
# see the fragment above
...DisplayPost
}
}
ব্যবহারকারীর দাবি দ্বারা ফিল্টার
এখানে, ধরে নিন যে আপনি কাস্টম ব্যবহারকারীর দাবিগুলি সেট করেছেন যা আপনার অ্যাপ্লিকেশনটির জন্য "প্রো" পরিকল্পনায় ব্যবহারকারীদের সনাক্ত করতে অ্যাথ টোকেনগুলিতে পাস করে, এটি auth.token.plan
ফিল্ডের সাথে অ্যাথ টোকেনের সাথে পতাকাঙ্কিত করে। আপনার অভিব্যক্তি এই ক্ষেত্রের বিরুদ্ধে পরীক্ষা করতে পারে।
# List all public or pro posts, only permitted if user has "pro" plan claim
query ProListPosts @auth(expr: "auth.token.plan == 'pro'") {
posts(where: {
# display both public posts and "pro" posts
visibility: {in: ['public', 'pro']},
# only display articles that are already published
publishedAt: {lt_expr: "request.time"},
}) {
# see the fragment above
...DisplayPost
# show visibility so pro users can see which posts are pro\
visibility
}
}
অর্ডার + সীমা দ্বারা ফিল্টার
বা আবারও, আপনি "প্রো" ব্যবহারকারীদের জন্য উপলভ্য বিষয়বস্তু সনাক্ত করার জন্য Post
রেকর্ডগুলিতে visibility
নির্ধারণ করতে পারেন, তবে ডেটাগুলির পূর্বরূপ বা টিজার তালিকার জন্য, ফিরে আসা রেকর্ডগুলির সংখ্যা আরও সীমাবদ্ধ করে।
# Show 2 oldest Pro post as a preview
query ProTeaser @auth(level: USER) {
posts(
where: {
# show only pro posts
visibility: {eq: "pro"}
# that have already been published more than 30 days ago
publishedAt: {lt_time: {now: true, sub: {days: 30}}}
},
# order by publish time
orderBy: [{publishedAt: DESC}],
# only return two posts
limit: 2
) {
# See the fragment above
...DisplayPost
}
}
ভূমিকা দ্বারা ফিল্টার
যদি আপনার কাস্টম দাবি কোনও admin
ভূমিকা সংজ্ঞায়িত করে তবে আপনি সেই অনুযায়ী অপারেশনগুলি পরীক্ষা করতে এবং অনুমোদিত করতে পারেন।
# List all posts unconditionally iff the current user has an admin claim
query AdminListPosts @auth(expr: "auth.token.admin == true") {
posts { ...DisplayPost }
}
@check
চেক এবং @redact
নির্দেশাবলী বুঝতে
@check
নির্দেশিকা যাচাই করে যে নির্দিষ্ট ক্ষেত্রগুলি কোয়েরি ফলাফলগুলিতে উপস্থিত রয়েছে। ক্ষেত্রের মানগুলি পরীক্ষা করতে একটি সাধারণ এক্সপ্রেশন ভাষা (সিএল) এক্সপ্রেশন ব্যবহৃত হয়। নির্দেশের ডিফল্ট আচরণ হ'ল null
-মূল্যবান নোডগুলি পরীক্ষা করা এবং প্রত্যাখ্যান করা।
@redact
ডাইরেক্টিভ ক্লায়েন্টের কাছ থেকে প্রতিক্রিয়ার একটি অংশকে redacts। রেড্যাক্টেড ক্ষেত্রগুলি এখনও পার্শ্ব প্রতিক্রিয়াগুলির জন্য মূল্যায়ন করা হয় (ডেটা পরিবর্তন এবং @check
সহ) এবং ফলাফলগুলি এখনও সেল এক্সপ্রেশনগুলির পরবর্তী পদক্ষেপগুলিতে উপলব্ধ।
Data Connect , @check
চেক এবং @redact
নির্দেশাবলী প্রায়শই অনুমোদনের চেকগুলির প্রসঙ্গে ব্যবহৃত হয়; অনুমোদনের ডেটা অনুসন্ধানের আলোচনাটি দেখুন।
অনুমোদনের ডেটা সন্ধান করতে @check
চেক এবং @redact
নির্দেশিকা যুক্ত করুন
একটি সাধারণ অনুমোদনের ব্যবহারের ক্ষেত্রে আপনার ডাটাবেসে কাস্টম অনুমোদনের ভূমিকাগুলি সংরক্ষণ করা জড়িত, উদাহরণস্বরূপ একটি বিশেষ অনুমতি সারণীতে এবং ডেটা তৈরি, আপডেট করতে বা মুছতে মিউটেশনগুলিকে অনুমোদনের জন্য সেই ভূমিকাগুলি ব্যবহার করে।
অনুমোদনের ডেটা লুকআপগুলি ব্যবহার করে, আপনি কোনও ইউজারআইডের উপর ভিত্তি করে ভূমিকার জন্য জিজ্ঞাসা করতে পারেন এবং রূপান্তরটি অনুমোদিত কিনা তা সিদ্ধান্ত নিতে সিইএল এক্সপ্রেশন ব্যবহার করতে পারেন। উদাহরণস্বরূপ, আপনি একটি UpdateMovieTitle
মিউটেশন লিখতে চাইতে পারেন যা কোনও অনুমোদিত ক্লায়েন্টকে মুভি শিরোনাম আপডেট করতে দেয়।
এই আলোচনার বাকি অংশগুলির জন্য, মুভি রিভিউ অ্যাপ্লিকেশন ডাটাবেসটি MoviePermission
টেবিলে একটি অনুমোদনের ভূমিকা সংরক্ষণ করে।
# MoviePermission
# Suppose a user has an authorization role with respect to records in the Movie table
type MoviePermission @table(key: ["movie", "user"]) {
movie: Movie! # implies another field: movieId: UUID!
user: User!
role: String!
}
মিউটেশনগুলিতে ব্যবহার করুন
নিম্নলিখিত উদাহরণ বাস্তবায়নে, UpdateMovieTitle
মিউটেশনটিতে MoviePermission
থেকে ডেটা পুনরুদ্ধার করার জন্য একটি query
ক্ষেত্র অন্তর্ভুক্ত রয়েছে এবং অপারেশনটি সুরক্ষিত এবং দৃ ust ় রয়েছে তা নিশ্চিত করার জন্য নিম্নলিখিত নির্দেশাবলী:
- সমস্ত অনুমোদনের প্রশ্ন এবং চেকগুলি পরমাণুভাবে সম্পূর্ণ বা ব্যর্থ হয়েছে তা নিশ্চিত করার জন্য একটি
@transaction
নির্দেশিকা। - প্রতিক্রিয়া থেকে ক্যোয়ারী ফলাফলগুলি বাদ দেওয়ার জন্য
@redact
নির্দেশিকা, যার অর্থ আমাদের অনুমোদনের চেকটি Data Connect সার্ভারে সঞ্চালিত হয় তবে সংবেদনশীল ডেটা ক্লায়েন্টের কাছে প্রকাশিত হয় না। ক্যোয়ারী ফলাফলগুলিতে অনুমোদনের যুক্তি মূল্যায়নের জন্য
@check
নির্দেশের একটি জুড়ি, যেমন কোনও প্রদত্ত ব্যবহারকারী আইডের পরিবর্তনগুলি করার জন্য উপযুক্ত ভূমিকা রয়েছে তা পরীক্ষা করে।
mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query @redact {
moviePermission( # Look up a join table called MoviePermission with a compound key.
key: {movieId: $movieId, userId_expr: "auth.uid"}
# Step 1a: Use @check to test if the user has any role associated with the movie
# Here the `this` binding refers the lookup result, i.e. a MoviePermission object or null
# The `this != null` expression could be omitted since rejecting on null is default behavior
) @check(expr: "this != null", message: "You do not have access to this movie") {
# Step 1b: Check if the user has the editor role for the movie
# Next we execute another @check; now `this` refers to the contents of the `role` field
role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
প্রশ্ন ব্যবহার করুন
অনুমোদনের ডেটা লুকআপগুলি ভূমিকা বা অন্যান্য বিধিনিষেধের ভিত্তিতে প্রশ্নগুলি সীমাবদ্ধ করতেও দরকারী।
নিম্নলিখিত উদাহরণে, যা MoviePermission
স্কিমাও ব্যবহার করে, ক্যোয়ারীটি কোনও অনুরোধকারীর ব্যবহারকারী যারা সিনেমা সম্পাদনা করতে পারে তাদের দেখার জন্য উপযুক্ত "অ্যাডমিন" ভূমিকা আছে কিনা তা পরীক্ষা করে।
query GetMovieEditors($movieId: UUID!) @auth(level: PUBLIC) {
moviePermission(key: { movieId: $movieId, userId_expr: "auth.uid" }) @redact {
role @check(expr: "this == 'admin'", message: "You must be an admin to view all editors of a movie.")
}
moviePermissions(where: { movieId: { eq: $movieId }, role: { eq: "editor" } }) {
user {
id
username
}
}
}
অনুমোদনে এড়াতে অ্যান্টিপ্যাটার্নস
পূর্ববর্তী বিভাগটি @auth
নির্দেশিকা ব্যবহার করার সময় অনুসরণ করতে নিদর্শনগুলি কভার করে।
এড়াতে আপনার গুরুত্বপূর্ণ অ্যান্টিপ্যাটার্নস সম্পর্কেও সচেতন হওয়া উচিত।
ক্যোয়ারী এবং মিউটেশন আর্গুমেন্টগুলিতে ব্যবহারকারীর বৈশিষ্ট্যগুলি আইডি এবং অ্যাথ টোকেন পরামিতিগুলি পাস করা এড়িয়ে চলুন
Firebase Authentication প্রমাণীকরণ প্রবাহ উপস্থাপনের জন্য এবং সুরক্ষিতভাবে প্রমাণীকরণের ডেটা যেমন নিবন্ধিত ব্যবহারকারী আইডি এবং অথ টোকেনে সঞ্চিত অসংখ্য ক্ষেত্রের মতো প্রমাণীকরণের ডেটা সুরক্ষিত করার জন্য একটি শক্তিশালী সরঞ্জাম।
ক্যোয়ারী এবং মিউটেশন আর্গুমেন্টগুলিতে ব্যবহারকারী আইডি এবং অ্যাথ টোকেন ডেটা পাস করার জন্য এটি প্রস্তাবিত অনুশীলন নয়।
# Antipattern!
# This incorrectly allows any user to view any other user's posts
query AllMyPosts($userId: String!) @auth(level: USER) {
posts(where: {authorUid: {eq: $userId}}) {
id, text, createdAt
}
}
কোনও ফিল্টার ছাড়াই USER
অ্যাক্সেস স্তর ব্যবহার করা এড়িয়ে চলুন
গাইডে বেশ কয়েকবার আলোচিত হিসাবে, USER
, USER_ANON
, USER_EMAIL_VERIFIED
মতো মূল অ্যাক্সেসের স্তরগুলি হ'ল বেসলাইন এবং অনুমোদনের চেকগুলির জন্য প্রারম্ভিক পয়েন্টগুলি, ফিল্টার এবং এক্সপ্রেশনগুলির সাথে বাড়ানো। সংশ্লিষ্ট ফিল্টার বা অভিব্যক্তি ছাড়াই এই স্তরগুলি ব্যবহার করে যা কোন ব্যবহারকারী অনুরোধটি সম্পাদন করছে তা পরীক্ষা করে যা PUBLIC
স্তর ব্যবহারের সমতুল্য।
# Antipattern!
# This incorrectly allows any user to view all documents
query ListDocuments @auth(level: USER) {
documents {
id
title
text
}
}
প্রোটোটাইপিংয়ের জন্য PUBLIC
বা USER
অ্যাক্সেস স্তর ব্যবহার করা এড়িয়ে চলুন
উন্নয়নের গতি বাড়ানোর জন্য, সমস্ত ক্রিয়াকলাপকে অনুমোদিত করার জন্য আরও বর্ধন ছাড়াই সমস্ত ক্রিয়াকলাপ বা PUBLIC
অ্যাক্সেস স্তরে সমস্ত অপারেশন সেট করা লোভনীয় হতে পারে এবং আপনাকে দ্রুত আপনার কোডটি পরীক্ষা করতে দেয় USER
আপনি যখন এইভাবে খুব প্রাথমিক প্রোটোটাইপিং করেছেন, তখন NO_ACCESS
থেকে উত্পাদন-প্রস্তুত অনুমোদনের দিকে PUBLIC
এবং USER
স্তরের সাথে স্যুইচ করতে শুরু করুন। তবে এই গাইডটিতে প্রদর্শিত হিসাবে অতিরিক্ত যুক্তি যুক্ত না করে এগুলি PUBLIC
বা USER
হিসাবে স্থাপন করবেন না।
# Antipattern!
# This incorrectly allows anyone to delete any post
mutation DeletePost($id: UUID!) @auth(level: PUBLIC) {
post: post_delete(
id: $id,
)
}
অ্যাপ্লিকেশন সত্যতার জন্য Firebase App Check ব্যবহার করুন
প্রমাণীকরণ এবং অনুমোদন Data Connect সুরক্ষার সমালোচনামূলক উপাদান। অ্যাপ্লিকেশন প্রমাণের সাথে মিলিত প্রমাণীকরণ এবং অনুমোদন খুব শক্তিশালী সুরক্ষা সমাধানের জন্য তৈরি করে।
Firebase App Check মাধ্যমে সত্যতা সহ, আপনার অ্যাপ্লিকেশনটি চালিত ডিভাইসগুলি একটি অ্যাপ্লিকেশন বা ডিভাইস সত্যতা সরবরাহকারী ব্যবহার করবে যা প্রমাণ করে যে Data Connect অপারেশনগুলি আপনার খাঁটি অ্যাপ্লিকেশন থেকে উদ্ভূত হয় এবং অনুরোধগুলি একটি খাঁটি, অনাবৃত ডিভাইস থেকে উদ্ভূত হয়। এই সত্যতাটি আপনার অ্যাপ্লিকেশনটি Data Connect করে প্রতিটি অনুরোধের সাথে সংযুক্ত থাকে।
Data Connect জন্য কীভাবে App Check সক্ষম করতে এবং আপনার অ্যাপ্লিকেশনটিতে এর ক্লায়েন্ট এসডিকে অন্তর্ভুক্ত করতে পারে তা শিখতে, App Check ওভারভিউটি দেখুন ।
@auth(level)
নির্দেশকের জন্য প্রমাণীকরণ স্তর
নিম্নলিখিত টেবিলটি সমস্ত স্ট্যান্ডার্ড অ্যাক্সেস স্তর এবং তাদের সিইএল সমতুল্য তালিকাভুক্ত করে। প্রমাণীকরণের স্তরগুলি বিস্তৃত থেকে সংকীর্ণ পর্যন্ত তালিকাভুক্ত করা হয় - প্রতিটি স্তর নিম্নলিখিত স্তরের সাথে মেলে এমন সমস্ত ব্যবহারকারীকে অন্তর্ভুক্ত করে।
স্তর | সংজ্ঞা |
---|---|
PUBLIC | অপারেশনটি প্রমাণীকরণের সাথে বা ছাড়াই যে কেউ দ্বারা সম্পাদন করা যেতে পারে। বিবেচনাগুলি: ডেটা কোনও ব্যবহারকারী দ্বারা পড়া বা সংশোধন করা যেতে পারে। ফায়ারবেস পণ্য বা মিডিয়া তালিকার মতো সর্বজনীন-ব্রাউজযোগ্য ডেটার জন্য এই স্তরের অনুমোদনের পরামর্শ দেয়। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন। @auth(expr: "true") @auth ফিল্টার এবং এক্সপ্রেশনগুলি এই অ্যাক্সেস স্তরের সাথে একত্রে ব্যবহার করা যাবে না। এই জাতীয় কোনও অভিব্যক্তি 400 টি খারাপ অনুরোধ ত্রুটির সাথে ব্যর্থ হবে। |
USER_ANON | যারা Firebase Authentication সাথে বেনামে লগ ইন করেছেন তাদের সহ যে কোনও চিহ্নিত ব্যবহারকারী ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। দ্রষ্টব্য: USER_ANON USER একটি সুপারসেট।বিবেচনাগুলি: নোট করুন যে অনুমোদনের এই স্তরের জন্য আপনাকে অবশ্যই আপনার প্রশ্ন এবং মিউটেশনগুলি সাবধানতার সাথে ডিজাইন করতে হবে। এই স্তরটি Authentication সাথে ব্যবহারকারীকে বেনামে (কেবলমাত্র কোনও ব্যবহারকারী ডিভাইসে আবদ্ধ স্বয়ংক্রিয় সাইন-ইন বেঁধে) লগ ইন করার অনুমতি দেয় এবং নিজের নিজস্ব চেকগুলি সম্পাদন করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্ভুক্ত কিনা। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন। যেহেতু Authentication বেনামে লগইন প্রবাহিত একটি uid ইস্যু করে, তাই USER_ANON স্তরটি সমতুল্য@auth(expr: "auth.uid != nil") |
USER | যে কোনও ব্যবহারকারী যিনি Firebase Authentication সাথে লগ ইন করেছেন তাকে বেনামে সাইন-ইন ব্যবহারকারীদের ব্যতীত ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। বিবেচনাগুলি: নোট করুন যে অনুমোদনের এই স্তরের জন্য আপনাকে অবশ্যই আপনার প্রশ্ন এবং মিউটেশনগুলি সাবধানতার সাথে ডিজাইন করতে হবে। এই স্তরটি কেবল চেক করে যে ব্যবহারকারী Authentication সাথে লগ ইন করেছেন, এবং নিজের নিজের উপর অন্য চেকগুলি সম্পাদন করেন না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন। @auth(expr: "auth.uid != nil && auth.token.firebase.sign_in_provider != 'anonymous'")" |
USER_EMAIL_VERIFIED | যে কোনও ব্যবহারকারী যিনি একটি যাচাই করা ইমেল ঠিকানা সহ Firebase Authentication সাথে লগ ইন করেছেন তাদের ক্যোয়ারী বা মিউটেশন সম্পাদনের জন্য অনুমোদিত। বিবেচনাগুলি: যেহেতু ইমেল যাচাইকরণ Authentication ব্যবহার করে সঞ্চালিত হয়, এটি আরও শক্তিশালী Authentication পদ্ধতির উপর ভিত্তি করে, সুতরাং এই স্তরটি USER বা USER_ANON তুলনায় অতিরিক্ত সুরক্ষা সরবরাহ করে। এই স্তরটি কেবল চেক করে যে ব্যবহারকারী একটি যাচাই করা ইমেলের সাথে Authentication সাথে লগ ইন করেছেন এবং এটি নিজস্বভাবে অন্য চেকগুলি সম্পাদন করে না, উদাহরণস্বরূপ, ডেটা ব্যবহারকারীর অন্তর্গত কিনা। সেরা অনুশীলনের উদাহরণ এবং বিকল্পগুলি দেখুন।@auth(expr: "auth.uid != nil && auth.token.email_verified")" |
NO_ACCESS | এই অপারেশনটি কোনও অ্যাডমিন এসডিকে প্রসঙ্গে কার্যকর করা যায় না।@auth(expr: "false") |
@auth(expr)
এবং @check(expr)
এর জন্য সেল রেফারেন্স
এই গাইডের অন্য কোথাও উদাহরণগুলিতে দেখানো হয়েছে, আপনি @auth(expr:)
এবং @check
নির্দেশাবলী ব্যবহার করে Data Connect জন্য অনুমোদন নিয়ন্ত্রণ করতে সাধারণ এক্সপ্রেশন ল্যাঙ্গুয়েজ (সিএল) এ সংজ্ঞায়িত এক্সপ্রেশনগুলি ব্যবহার করতে পারেন এবং ব্যবহার করতে পারেন।
এই বিভাগটি এই নির্দেশাবলীর জন্য অভিব্যক্তি তৈরির জন্য প্রাসঙ্গিক সিইএল সিনট্যাক্সকে কভার করে।
সিইএল এর জন্য সম্পূর্ণ রেফারেন্স তথ্য সিইএল স্পেসিফিকেশনে সরবরাহ করা হয়।
পরীক্ষার ভেরিয়েবলগুলি প্রশ্ন এবং মিউটেশনে পাস করেছে
@auth(expr)
সিনট্যাক্স আপনাকে কোয়েরি এবং মিউটেশনগুলি থেকে ভেরিয়েবলগুলি অ্যাক্সেস এবং পরীক্ষার অনুমতি দেয়।
উদাহরণস্বরূপ, আপনি vars.status
ব্যবহার করে একটি অপারেশন ভেরিয়েবল যেমন $status
অন্তর্ভুক্ত করতে পারেন।
mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")
এক্সপ্রেশনগুলিতে ডেটা উপলব্ধ
উভয়ই @auth(expr:)
এবং @check(expr:)
সেল এক্সপ্রেশনগুলি নিম্নলিখিতগুলি মূল্যায়ন করতে পারে:
-
request.operationName
-
vars
(request.variables
জন্য ওরফে। ভেরিয়েবলস) -
auth
(request.auth
জন্য ওরফে।
অতিরিক্তভাবে, @check(expr:)
এক্সপ্রেশনগুলি মূল্যায়ন করতে পারে:
-
this
(বর্তমান ক্ষেত্রের মান)
অনুরোধ.অপ্রেশন নাম অবজেক্ট
request.operarationName
নাম অবজেক্টটি অপারেশনের ধরণটি সঞ্চয় করে, ক্যোয়ারী বা মিউটেশন হয়।
vars
অবজেক্ট
vars
অবজেক্টটি আপনার এক্সপ্রেশনগুলিকে আপনার ক্যোয়ারী বা মিউটেশনে পাস করা সমস্ত ভেরিয়েবলগুলি অ্যাক্সেস করতে দেয়।
আপনি সম্পূর্ণরূপে যোগ্যতার request.variables.<variablename>
জন্য একটি উপন্যাস হিসাবে একটি অভিব্যক্তিতে vars.<variablename>
ব্যবহার করতে পারেন <ভেরিব্লেনাম>।
# The following are equivalent
mutation StringType($v: String!) @auth(expr: "vars.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")
auth
অবজেক্ট
Authentication ব্যবহারকারীদের আপনার ডেটাতে অ্যাক্সেসের জন্য অনুরোধ করে সনাক্ত করে এবং সেই তথ্যটি এমন একটি বস্তু হিসাবে সরবরাহ করে যা আপনি আপনার অভিব্যক্তিগুলিতে তৈরি করতে পারেন।
আপনার ফিল্টার এবং এক্সপ্রেশনগুলিতে, আপনি request.auth
জন্য একটি নাম হিসাবে auth
ব্যবহার করতে পারেন a
লেখক অবজেক্টে নিম্নলিখিত তথ্য রয়েছে:
-
uid
: একটি অনন্য ব্যবহারকারী আইডি, অনুরোধকারী ব্যবহারকারীকে বরাদ্দ করা হয়েছে। -
token
: Authentication দ্বারা সংগৃহীত মানগুলির একটি মানচিত্র।
auth.token
এর অবিচ্ছিন্ন সম্পর্কে আরও তথ্যের জন্য আথ টোকেনগুলিতে ডেটা দেখুন
this
বাঁধাই
this
বাঁধাই এই ক্ষেত্রের সাথে মূল্যায়ন করে যা @check
নির্দেশিকাটি সংযুক্ত রয়েছে। একটি প্রাথমিক ক্ষেত্রে, আপনি একক মূল্যবান ক্যোয়ারী ফলাফল মূল্যায়ন করতে পারেন।
mutation UpdateMovieTitle($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query @redact {
moviePermission( # Look up a join table called MoviePermission with a compound key.
key: {movieId: $movieId, userId_expr: "auth.uid"}
) {
# Check if the user has the editor role for the movie. `this` is the string value of `role`.
# If the parent moviePermission is null, the @check will also fail automatically.
role @check(expr: "this == 'editor'", message: "You must be an editor of this movie to update title")
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
যদি ফেরত ক্ষেত্রটি একাধিকবার ঘটে কারণ যে কোনও পূর্বপুরুষ একটি তালিকা, প্রতিটি ঘটনা প্রতিটি মানের সাথে this
আবদ্ধ দিয়ে পরীক্ষা করা হয়।
যে কোনও প্রদত্ত পথের জন্য, যদি কোনও পূর্বপুরুষ null
বা []
হয় তবে ক্ষেত্রটি পৌঁছে যাবে না এবং সেল মূল্যায়ন সেই পথে এড়িয়ে যাবে। অন্য কথায়, মূল্যায়ন কেবল তখনই ঘটে যখন this
null
বা অ- null
হয়, তবে কখনই undefined
না।
যখন ক্ষেত্রটি নিজেই একটি তালিকা বা অবজেক্ট হয়, this
একই কাঠামো অনুসরণ করে (অবজেক্টের ক্ষেত্রে নির্বাচিত সমস্ত সিদ্ধান্ত সহ), নিম্নলিখিত উদাহরণে চিত্রিত হিসাবে।
mutation UpdateMovieTitle2($movieId: UUID!, $newTitle: String!) @auth(level: USER) @transaction {
# Step 1: Query and check
query {
moviePermissions( # Now we query for a list of all matching MoviePermissions.
where: {movieId: {eq: $movieId}, userId: {eq_expr: "auth.uid"}}
# This time we execute the @check on the list, so `this` is the list of objects.
# We can use the `.exists` macro to check if there is at least one matching entry.
) @check(expr: "this.exists(p, p.role == 'editor')", message: "You must be an editor of this movie to update title") {
role
}
}
# Step 2: Act
movie_update(id: $movieId, data: {
title: $newTitle
})
}
জটিল এক্সপ্রেশন সিনট্যাক্স
আপনি &&
এর সাথে একত্রিত হয়ে আরও জটিল অভিব্যক্তি লিখতে পারেন এবং ||
অপারেটর
mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (vars.username == 'joe')")
নিম্নলিখিত বিভাগটি সমস্ত উপলভ্য অপারেটর বর্ণনা করে।
অপারেটর এবং অপারেটর অগ্রাধিকার
অপারেটর এবং তাদের সম্পর্কিত অগ্রাধিকারের জন্য একটি রেফারেন্স হিসাবে নিম্নলিখিত টেবিলটি ব্যবহার করুন।
নির্বিচারে অভিব্যক্তি a
এবং b
, একটি ক্ষেত্র f
এবং একটি সূচক i
।
অপারেটর | বর্ণনা | সহযোগীতা |
---|---|---|
a[i] a() af | সূচক, কল, ক্ষেত্র অ্যাক্সেস | বাম থেকে ডান |
!a -a | ইউনারি নেগেটিভ | ডান থেকে বাম |
a/ba%ba*b | মাল্টিপ্লেটিভ অপারেটর | বাম থেকে ডান |
a+b ab | সংযোজন অপারেটর | বাম থেকে ডান |
a>b a>=b a<b a<=b | রিলেশনাল অপারেটর | বাম থেকে ডান |
a in b | তালিকা বা মানচিত্রে অস্তিত্ব | বাম থেকে ডান |
type(a) == t | তুলনা টাইপ করুন, যেখানে t বুল, ইনট, ফ্লোট, সংখ্যা, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প বা সময়কাল হতে পারে | বাম থেকে ডান |
a==ba!=b | তুলনা অপারেটর | বাম থেকে ডান |
a && b | শর্তাধীন এবং | বাম থেকে ডান |
a || b | শর্তাধীন বা | বাম থেকে ডান |
a ? true_value : false_value | টেরিনারি এক্সপ্রেশন | বাম থেকে ডান |
অ্যাথ টোকেনগুলিতে ডেটা
auth.token
অবজেক্টে নিম্নলিখিত মানগুলি থাকতে পারে:
মাঠ | বর্ণনা |
---|---|
email | অ্যাকাউন্টের সাথে সম্পর্কিত ইমেল ঠিকানা, উপস্থিত থাকলে। |
email_verified | true যদি ব্যবহারকারী যাচাই করে থাকেন তবে তাদের email ঠিকানায় অ্যাক্সেস রয়েছে। কিছু সরবরাহকারী স্বয়ংক্রিয়ভাবে তাদের নিজস্ব ইমেল ঠিকানাগুলি যাচাই করে। |
phone_number | অ্যাকাউন্টের সাথে যুক্ত ফোন নম্বর, উপস্থিত থাকলে। |
name | ব্যবহারকারীর প্রদর্শনের নাম, যদি সেট করা হয়। |
sub | ব্যবহারকারীর ফায়ারবেস ইউআইডি। এটি একটি প্রকল্পের মধ্যে অনন্য। |
firebase.identities | এই ব্যবহারকারীর অ্যাকাউন্টের সাথে সম্পর্কিত সমস্ত পরিচয়ের অভিধান। অভিধানের কীগুলি নিম্নলিখিতগুলির মধ্যে যে কোনও হতে পারে: email , phone , google.com , facebook.com , github.com , twitter.com । অভিধানের মানগুলি অ্যাকাউন্টের সাথে সম্পর্কিত প্রতিটি পরিচয় সরবরাহকারীর জন্য অনন্য শনাক্তকারীদের অ্যারে। উদাহরণস্বরূপ, auth.token.firebase.identities["google.com"][0] অ্যাকাউন্টের সাথে সম্পর্কিত প্রথম গুগল ব্যবহারকারী আইডি রয়েছে। |
firebase.sign_in_provider | সাইন-ইন সরবরাহকারী এই টোকেনটি পেতে ব্যবহৃত হত। নিম্নলিখিত স্ট্রিংগুলির মধ্যে একটি হতে পারে: custom , password , phone , anonymous , google.com , facebook.com , github.com , twitter.com । |
firebase.tenant | অ্যাকাউন্টের সাথে যুক্ত টেনানটিড, উপস্থিত থাকলে। উদাহরণস্বরূপ, tenant2-m6tyz |
জেডব্লিউটি আইডি টোকেনগুলিতে অতিরিক্ত ক্ষেত্র
আপনি নিম্নলিখিত auth.token
ক্ষেত্রগুলিও অ্যাক্সেস করতে পারেন:
কাস্টম টোকেন দাবি | ||
---|---|---|
alg | অ্যালগরিদম | "RS256" |
iss | ইস্যুকারী | আপনার প্রকল্পের পরিষেবা অ্যাকাউন্ট ইমেল ঠিকানা |
sub | বিষয় | আপনার প্রকল্পের পরিষেবা অ্যাকাউন্ট ইমেল ঠিকানা |
aud | শ্রোতা | "https://identitytoolkit.googleapis.com/google.identity.identitytoolkit.v1.IdentityToolkit" |
iat | জারি-সময় | বর্তমান সময়, ইউনিক্স যুগের পরে কয়েক সেকেন্ডে |
exp | মেয়াদ শেষ হওয়ার সময় | সময়, ইউনিক্স যুগের পরে কয়েক সেকেন্ডের মধ্যে, যেখানে টোকেনের মেয়াদ শেষ হয়। এটি iat চেয়ে সর্বোচ্চ 3600 সেকেন্ড পরে হতে পারে।দ্রষ্টব্য: এটি কেবল সেই সময়টিকে নিয়ন্ত্রণ করে যখন কাস্টম টোকেন নিজেই মেয়াদ শেষ হয়। তবে একবার আপনি কোনও ব্যবহারকারীকে signInWithCustomToken() ব্যবহার করতে স্বাক্ষর করলে তারা তাদের সেশনটি অবৈধ না হওয়া বা ব্যবহারকারী সাইন আউট না হওয়া পর্যন্ত তারা ডিভাইসে সাইন ইন থাকবে। |
<claims> (al চ্ছিক) | Oke চ্ছিক কাস্টম দাবিগুলি টোকেনে অন্তর্ভুক্ত করার দাবি করে, যা এক্সপ্রেশনগুলিতে auth.token (বা request.auth.token ) এর মাধ্যমে অ্যাক্সেস করা যায়। উদাহরণস্বরূপ, আপনি যদি একটি কাস্টম দাবি adminClaim তৈরি করেন তবে আপনি এটি auth.token.adminClaim দিয়ে অ্যাক্সেস করতে পারেন। |
এরপর কি?
- Firebase Data Connect আপনাকে সুবিধাযুক্ত পরিবেশ থেকে প্রশ্ন এবং মিউটেশনগুলি সম্পাদন করতে একটি অ্যাডমিন এসডিকে সরবরাহ করে।
- পরিষেবা এবং ডাটাবেস পরিচালনার জন্য গাইডে আইএএম সুরক্ষা সম্পর্কে জানুন।