অনুমোদন এবং সত্যায়নের সাথে সুরক্ষিত ডেটা সংযোগ, অনুমোদন এবং সত্যায়নের সাথে সুরক্ষিত ডেটা সংযোগ, অনুমোদন এবং সত্যায়নের সাথে নিরাপদ ডেটা সংযোগ

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 দ্বারা প্রদত্ত প্রমাণীকরণ প্রবাহের সাথে সম্পর্কযুক্ত।

প্রারম্ভিক বিন্দু হিসাবে এই প্রিসেট অ্যাক্সেস লেভেলগুলি ব্যবহার করে, আপনি সার্ভারে 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 সমতুল্য তালিকা রয়েছে। প্রমাণীকরণ স্তরগুলি বিস্তৃত থেকে সংকীর্ণ পর্যন্ত তালিকাভুক্ত করা হয়েছে -- প্রতিটি স্তর নিম্নলিখিত স্তরগুলির সাথে মেলে এমন সমস্ত ব্যবহারকারীকে অন্তর্ভুক্ত করে৷

@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 .

প্রমাণীকরণ টোকেনে ডেটা

auth.token অবজেক্টে নিম্নলিখিত মান থাকতে পারে:

JWT আইডি টোকেনে অতিরিক্ত ক্ষেত্র

এছাড়াও আপনি নিম্নলিখিত auth.token ক্ষেত্রগুলিতে অ্যাক্সেস করতে পারেন:

এরপর কি?

• Firebase Data Connect একটি অ্যাডমিন SDK প্রদান করে যাতে আপনি বিশেষ সুবিধাপ্রাপ্ত পরিবেশ থেকে প্রশ্ন এবং মিউটেশন করতে পারেন।
• পরিষেবা এবং ডাটাবেস পরিচালনার জন্য গাইডে IAM নিরাপত্তা সম্পর্কে জানুন।