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

Firebase Data Connect এর সাথে শক্তিশালী ক্লায়েন্ট-সাইড নিরাপত্তা প্রদান করে:

  • মোবাইল এবং ওয়েব ক্লায়েন্ট অনুমোদন
  • স্বতন্ত্র প্রশ্ন- এবং মিউটেশন-স্তরের অনুমোদন নিয়ন্ত্রণ
  • Firebase App Check সহ অ্যাপ প্রত্যয়ন।

Data Connect এই নিরাপত্তা প্রসারিত করে:

  • সার্ভার-সাইড অনুমোদন
  • ফায়ারবেস প্রজেক্ট এবং ক্লাউড এসকিউএল ব্যবহারকারী নিরাপত্তা আইএএম-এর সাথে।

ক্লায়েন্ট প্রশ্ন এবং মিউটেশন অনুমোদন

Data Connect সম্পূর্ণরূপে Firebase Authentication সাথে একত্রিত করা হয়েছে, তাই আপনি সেই ব্যবহারকারীদের সম্পর্কে সমৃদ্ধ ডেটার সুবিধা নিতে পারেন যারা আপনার ডিজাইনে আপনার ডেটা (প্রমাণিকরণ) অ্যাক্সেস করছে সেই ব্যবহারকারীরা কোন ডেটা অ্যাক্সেস করতে পারে (অনুমোদন)।

Data Connect প্রশ্ন এবং মিউটেশনের জন্য একটি @auth নির্দেশনা প্রদান করে যা আপনাকে অপারেশন অনুমোদন করার জন্য প্রয়োজনীয় প্রমাণীকরণের স্তর সেট করতে দেয়।

@auth নির্দেশ বুঝুন

আপনি অনেকগুলি সাধারণ অ্যাক্সেসের পরিস্থিতি কভার করে এমন কয়েকটি প্রিসেট অ্যাক্সেস লেভেলের একটি অনুসরণ করতে @auth নির্দেশকে প্যারামিটারাইজ করতে পারেন। এই স্তরগুলি PUBLIC (যা কোনো প্রকারের প্রমাণীকরণ ছাড়াই সমস্ত ক্লায়েন্টের কাছ থেকে প্রশ্ন এবং মিউটেশনের অনুমতি দেয়) থেকে NO_ACCESS পর্যন্ত (যা ফায়ারবেস অ্যাডমিন SDK ব্যবহার করে বিশেষ সুবিধাপ্রাপ্ত সার্ভার পরিবেশের বাইরে প্রশ্ন এবং মিউটেশন অনুমোদন করে)। এই স্তরগুলির প্রতিটি Firebase Authentication দ্বারা প্রদত্ত প্রমাণীকরণ প্রবাহের সাথে সম্পর্কযুক্ত।

প্রারম্ভিক বিন্দু হিসাবে এই প্রিসেট অ্যাক্সেস স্তরগুলি ব্যবহার করে, আপনি সার্ভারে মূল্যায়ন করা পরীক্ষার ফিল্টার এবং অভিব্যক্তিগুলি ব্যবহার করে @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 }
}

অনুমোদন এড়াতে অ্যান্টিপ্যাটার্নস

পূর্ববর্তী বিভাগে @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) এর জন্য CEL রেফারেন্স

পরীক্ষা ভেরিয়েবল প্রশ্ন এবং মিউটেশন পাস

পূর্বে ইঙ্গিত করা হয়েছে, @auth(expr) সিনট্যাক্স আপনাকে প্রশ্ন এবং মিউটেশন থেকে ভেরিয়েবল অ্যাক্সেস এবং পরীক্ষা করার অনুমতি দেয়।

আপনি হয় একটি অপারেশন ভেরিয়েবল অন্তর্ভুক্ত করতে পারেন, উদাহরণস্বরূপ $status , নামের status ব্যবহার করে অথবা সম্পূর্ণ-যোগ্য request.variables.status ব্যবহার করে।

# The following are equivalent
mutation Update($id: UUID!, $status: Any) @auth(expr: "has(request.variables.status)")
mutation Update($id: UUID!, $status: Any) @auth(expr: "has(status)")`

জটিল অভিব্যক্তি বাক্য গঠন

আপনি && এবং || এর সাথে একত্রিত করে আরও জটিল অভিব্যক্তি লিখতে পারেন অপারেটর

mutation UpsertUser($username: String!) @auth(expr: "(auth != null) && (username == 'joe')")

নিম্নলিখিত বিভাগে সমস্ত উপলব্ধ অপারেটর বর্ণনা করা হয়েছে.

অপারেটর এবং অপারেটর অগ্রাধিকার

অপারেটর এবং তাদের সংশ্লিষ্ট অগ্রাধিকারের জন্য একটি রেফারেন্স হিসাবে নীচের টেবিলটি ব্যবহার করুন।

প্রদত্ত নির্বিচারে অভিব্যক্তি a এবং b , একটি ক্ষেত্র f , এবং একটি সূচক i .

অপারেটর বর্ণনা সহযোগীতা
a[i] a() af সূচক, কল, ক্ষেত্র অ্যাক্সেস বাম থেকে ডান
!a -a ইউনারি নেগেটিভ ডান থেকে বাম
a/ba%ba*b মাল্টিপ্লেটিভ অপারেটর বাম থেকে ডান
a+b ab সংযোজন অপারেটর বাম থেকে ডান
a>ba>=ba রিলেশনাল অপারেটর বাম থেকে ডান
a in b তালিকা বা মানচিত্রে অস্তিত্ব বাম থেকে ডান
a is type টাইপ তুলনা, যেখানে type হতে পারে bool, int, float, number, স্ট্রিং, তালিকা, মানচিত্র, টাইমস্ট্যাম্প, সময়কাল, পথ বা latlng বাম থেকে ডান
a==ba!=b তুলনা অপারেটর বাম থেকে ডান
a && b শর্তাধীন এবং বাম থেকে ডান
a || b শর্তাধীন বা বাম থেকে ডান
a ? true_value : false_value টার্নারি এক্সপ্রেশন বাম থেকে ডান

এক্সপ্রেশনের জন্য উপলভ্য ডেটা

CEL এক্সপ্রেশন নিম্নলিখিতগুলির মধ্যে একটি মূল্যায়ন করতে পারে:

  • request.operationName
  • request.variables
  • request.auth

request.operationName অবজেক্ট

request.operarationName অবজেক্ট অপারেশনের ধরন সঞ্চয় করে, হয় প্রশ্ন বা মিউটেশন।

request.variables অবজেক্ট

request.variables

আপনি সম্পূর্ণরূপে-যোগ্য request.variables নামের জন্য একটি উপনাম হিসাবে একটি অভিব্যক্তিতে একটি পরিবর্তনশীল নাম ব্যবহার করতে পারেন:

# The following are equivalent
mutation StringType($v: String!) @auth(expr: "request.variables.v == 'hello'")
mutation StringType($v: String!) @auth(expr: "v == 'hello'")

request.auth অবজেক্ট

Authentication আপনার ডেটাতে অ্যাক্সেসের অনুরোধকারী ব্যবহারকারীদের সনাক্ত করে এবং সেই তথ্যটিকে একটি পরিবর্তনশীল হিসাবে প্রদান করে যা আপনি আপনার অভিব্যক্তিতে ব্যবহার করতে পারেন।

auth ভেরিয়েবলে নিম্নলিখিত তথ্য রয়েছে:

  • uid : একটি অনন্য ব্যবহারকারী আইডি, অনুরোধকারী ব্যবহারকারীকে বরাদ্দ করা হয়েছে।
  • token : প্রমাণীকরণ দ্বারা সংগৃহীত মানগুলির একটি মানচিত্র।

প্রমাণীকরণ টোকেনগুলিতে ডেটা সর্বদা উপস্থিত থাকে

auth ভেরিয়েবলে নিম্নলিখিত (প্রয়োজনীয়) মান রয়েছে:

মাঠ বর্ণনা
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() ব্যবহার করে কোনো ব্যবহারকারীকে সাইন ইন করলে, তাদের সেশন বাতিল না হওয়া পর্যন্ত বা ব্যবহারকারী সাইন আউট না হওয়া পর্যন্ত তারা ডিভাইসে সাইন ইন থাকবে।
uid সাইন-ইন করা ব্যবহারকারীর অনন্য শনাক্তকারী অবশ্যই একটি স্ট্রিং হতে হবে, 1-128 অক্ষরের মধ্যে লম্বা, অন্তর্ভুক্ত। সংক্ষিপ্ত uid গুলি আরও ভাল কর্মক্ষমতা অফার করে।
claims (ঐচ্ছিক) অভিব্যক্তি auth request.auth ভেরিয়েবল অন্তর্ভুক্ত করার জন্য ঐচ্ছিক কাস্টম দাবি

এরপর কি?