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

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

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

Data Connect এই নিরাপত্তা বৃদ্ধি করে:

• সার্ভার-সাইড অনুমোদন
• IAM এর সাথে Firebase প্রকল্প এবং ক্লাউড SQL ব্যবহারকারীর নিরাপত্তা।

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

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

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

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

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

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

এই প্রিসেট অ্যাক্সেস লেভেলগুলিকে একটি সূচনা বিন্দু হিসেবে ব্যবহার করে, আপনি @auth নির্দেশিকায় জটিল এবং শক্তিশালী অনুমোদন পরীক্ষা সংজ্ঞায়িত করতে পারেন where সার্ভারে ফিল্টার এবং কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (CEL) এক্সপ্রেশন মূল্যায়ন করা হয়।

সাধারণ অনুমোদনের পরিস্থিতি বাস্তবায়নের জন্য @auth নির্দেশিকা ব্যবহার করুন

প্রিসেট অ্যাক্সেস লেভেল হল অনুমোদনের সূচনা বিন্দু ।

শুরু করার জন্য USER অ্যাক্সেস লেভেল হল সবচেয়ে ব্যাপকভাবে কার্যকর মৌলিক লেভেল।

সম্পূর্ণ নিরাপদ অ্যাক্সেস USER স্তরের উপর ভিত্তি করে তৈরি হবে এবং এর সাথে ফিল্টার এবং এক্সপ্রেশন থাকবে যা ব্যবহারকারীর বৈশিষ্ট্য, সম্পদ বৈশিষ্ট্য, ভূমিকা এবং অন্যান্য পরীক্ষা পরীক্ষা করবে। USER_ANON এবং USER_EMAIL_VERIFIED স্তরগুলি USER ক্ষেত্রে ভিন্নতা।

এক্সপ্রেশন সিনট্যাক্স আপনাকে একটি auth অবজেক্ট ব্যবহার করে ডেটা মূল্যায়ন করতে দেয় যা অপারেশনের মাধ্যমে পাস করা প্রমাণীকরণ ডেটা উপস্থাপন করে, 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 এর মালিকানা।

নিম্নলিখিত উদাহরণগুলিতে, auth টোকেন থেকে ডেটা এক্সপ্রেশন ব্যবহার করে পড়া এবং তুলনা করা হয়। সাধারণ প্যাটার্ন হল where: {authorUid: {eq_expr: "auth.uid"}} মতো এক্সপ্রেশন ব্যবহার করে একটি সঞ্চিত authorUid সাথে প্রমাণীকরণ টোকেনে পাস করা auth.uid (ব্যবহারকারী আইডি) এর তুলনা করা।

তৈরি করুন

এই অনুমোদন অনুশীলনটি পরবর্তী অনুমোদন পরীক্ষায় তুলনা করার জন্য auth টোকেন থেকে auth.uid authorUid ক্ষেত্র হিসেবে প্রতিটি নতুন Post যোগ করে শুরু হয়।

# 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 "public" তে সেট করা আছে।

# 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 টোকেন পাস করে, auth টোকেনে একটি 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 নির্দেশিকা যোগ করুন।

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

অনুমোদনের ডেটা লুকআপ ব্যবহার করে, আপনি একটি ব্যবহারকারী আইডির উপর ভিত্তি করে ভূমিকা অনুসন্ধান করতে পারেন এবং মিউটেশন অনুমোদিত কিনা তা নির্ধারণ করতে 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 অ্যাক্সেস লেভেলে সেট করা প্রলুব্ধকর হতে পারে যাতে আরও বর্ধিতকরণ ছাড়াই সমস্ত অপারেশন অনুমোদন করা যায় এবং আপনাকে দ্রুত আপনার কোড পরীক্ষা করতে দেওয়া যায়।

এইভাবে প্রাথমিক প্রোটোটাইপিং সম্পন্ন করার পর, PUBLIC এবং USER লেভেল ব্যবহার করে NO_ACCESS থেকে প্রোডাকশন-রেডি অথোরাইজেশনে স্যুইচ করা শুরু করুন। তবে, এই নির্দেশিকায় দেখানো অতিরিক্ত লজিক যোগ না করে PUBLIC বা USER হিসেবে এগুলি স্থাপন করবেন না।

# Antipattern!
# This incorrectly allows anyone to delete any post
mutation DeletePost($id: UUID!) @auth(level: PUBLIC) {
  post: post_delete(
    id: $id,
  )
}

যাচাই না করা ইমেল ঠিকানার উপর ভিত্তি করে অনুমোদন এড়িয়ে চলুন

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

# Antipattern!
# Anyone can claim an email address during sign-in
mutation CreatePost($text: String!, $visibility: String) @auth(expr: "auth.token.email.endsWith('@example.com')") {
  post_insert(data: {
    # set the author's uid to the current user uid
    authorUid_expr: "auth.uid"
    text: $text
    visibility: $visibility
  })
}

এছাড়াও auth.token.email_verified চেক করুন

mutation CreatePost($text: String!, $visibility: String) @auth(expr: "auth.token.email_verified && auth.token.email.endsWith('@example.com')") {
  post_insert(data: {
    # set the author's uid to the current user uid
    authorUid_expr: "auth.uid"
    text: $text
    visibility: $visibility
  })
}

Firebase CLI এর মাধ্যমে অডিট অনুমোদন

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

Firebase CLI থেকে firebase deploy ব্যবহার করে সার্ভারে স্থাপন করার সময় Data Connect আপনার সংযোগকারী কোড বিশ্লেষণ করে আপনার অনুমোদন কৌশল অডিট করতে সাহায্য করে। আপনি আপনার কোডবেস পর্যালোচনা করতে সাহায্য করার জন্য এই অডিট ব্যবহার করতে পারেন।

যখন আপনি আপনার সংযোগকারী স্থাপন করবেন, তখন CLI আপনার সংযোগকারীতে বিদ্যমান, পরিবর্তিত এবং নতুন অপারেশন কোডের মূল্যায়ন আউটপুট করবে।

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

সতর্কতা এবং প্রম্পট সর্বদা নিম্নলিখিত ক্ষেত্রে ঘটে:

• PUBLIC

এবং, auth.uid ব্যবহার করে ফিল্টার ব্যবহার না করলে নিম্নলিখিত অ্যাক্সেস লেভেলগুলিতে সতর্কতা এবং প্রম্পট দেখা দেয়:

• USER
• USER_ANON
• USER_EMAIL_VERIFIED

@auth(insecureReason:) আর্গুমেন্ট ব্যবহার করে অনিরাপদ অপারেশন সতর্কতা দমন করুন।

অনেক ক্ষেত্রে, আপনি এই সিদ্ধান্তে উপনীত হবেন যে PUBLIC এবং USER* অ্যাক্সেস লেভেল ব্যবহার করা পুরোপুরি উপযুক্ত।

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

@auth(insecureReason:) ব্যবহার করে আপনি এই ধরনের অপারেশনের জন্য সতর্কতা দমন করতে পারেন। উদাহরণস্বরূপ:

query listItem @auth(level: PUBLIC, insecureReason: "This operation is safe to expose to the public.")
  {
    items {
      id name
    }
  }

অ্যাপ প্রত্যয়নের জন্য Firebase App Check ব্যবহার করুন

Data Connect নিরাপত্তার ক্ষেত্রে প্রমাণীকরণ এবং অনুমোদন অত্যন্ত গুরুত্বপূর্ণ উপাদান। অ্যাপ প্রত্যয়নের সাথে প্রমাণীকরণ এবং অনুমোদন একত্রিত করলে এটি একটি অত্যন্ত শক্তিশালী নিরাপত্তা সমাধান তৈরি করে।

Firebase App Check মাধ্যমে প্রত্যয়নের মাধ্যমে, আপনার অ্যাপটি চালানো ডিভাইসগুলি এমন একটি অ্যাপ বা ডিভাইস প্রত্যয়ন প্রদানকারী ব্যবহার করবে যা প্রমাণ করে যে Data Connect ক্রিয়াকলাপগুলি আপনার খাঁটি অ্যাপ থেকে উদ্ভূত এবং অনুরোধগুলি একটি খাঁটি, অ-ট্যাম্পারড ডিভাইস থেকে উদ্ভূত। এই প্রত্যয়নটি আপনার অ্যাপ Data Connect এর কাছে করা প্রতিটি অনুরোধের সাথে সংযুক্ত থাকে।

Data Connect জন্য App Check কীভাবে সক্ষম করবেন এবং আপনার অ্যাপে এর ক্লায়েন্ট SDK কীভাবে অন্তর্ভুক্ত করবেন তা জানতে, App Check ওভারভিউটি দেখুন ।

@auth(level) নির্দেশিকার জন্য প্রমাণীকরণ স্তর

নিম্নলিখিত সারণীতে সমস্ত স্ট্যান্ডার্ড অ্যাক্সেস স্তর এবং তাদের CEL সমতুল্য তালিকাভুক্ত করা হয়েছে। প্রমাণীকরণ স্তরগুলি বিস্তৃত থেকে সংকীর্ণ পর্যন্ত তালিকাভুক্ত করা হয়েছে -- প্রতিটি স্তরে নিম্নলিখিত স্তরগুলির সাথে মেলে এমন সমস্ত ব্যবহারকারী অন্তর্ভুক্ত রয়েছে।

@auth(expr) এর জন্য CEL রেফারেন্স

এই নির্দেশিকার অন্য কোথাও উদাহরণে যেমন দেখানো হয়েছে, আপনি @auth(expr:) এবং @check নির্দেশিকা ব্যবহার করে Data Connect অনুমোদন নিয়ন্ত্রণ করতে কমন এক্সপ্রেশন ল্যাঙ্গুয়েজ (CEL) তে সংজ্ঞায়িত এক্সপ্রেশন ব্যবহার করতে পারেন এবং ব্যবহার করা উচিত।

এই বিভাগটি এই নির্দেশাবলীর জন্য এক্সপ্রেশন তৈরির সাথে প্রাসঙ্গিক CEL সিনট্যাক্স কভার করে।

CEL-এর সম্পূর্ণ রেফারেন্স তথ্য CEL স্পেসিফিকেশনে দেওয়া আছে।

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

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

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

mutation Update($id: UUID!, $status: Any) @auth(expr: "has(vars.status)")

এক্সপ্রেশনের জন্য উপলব্ধ ডেটা: অনুরোধ, প্রতিক্রিয়া, এটি

আপনি নিম্নলিখিতগুলির জন্য ডেটা ব্যবহার করেন:

• @auth(expr:) এবং @check(expr:) নির্দেশিকায় CEL এক্সপ্রেশন ব্যবহার করে মূল্যায়ন
• সার্ভার এক্সপ্রেশন ব্যবহার করে অ্যাসাইনমেন্ট, <field>_expr ।

@auth(expr:) এবং @check(expr:) CEL এক্সপ্রেশন উভয়ই নিম্নলিখিতগুলি মূল্যায়ন করতে পারে:

• request.operationName
• vars ( request.variables এর উপনাম)
• auth ( request.auth এর উপনাম)

মিউটেশনে, আপনি নিম্নলিখিত বিষয়বস্তু অ্যাক্সেস এবং বরাদ্দ করতে পারেন:

• response (বহু-পদক্ষেপ যুক্তিতে আংশিক ফলাফল পরীক্ষা করার জন্য)

অতিরিক্তভাবে, @check(expr:) এক্সপ্রেশনগুলি মূল্যায়ন করতে পারে:

• this (বর্তমান ক্ষেত্রের মান)
• response (বহু-পদক্ষেপ যুক্তিতে আংশিক ফলাফল পরীক্ষা করার জন্য)

request.operationName বাইন্ডিং

request.operarationName বাইন্ডিং অপারেশনের ধরণ সংরক্ষণ করে, হয় কোয়েরি অথবা মিউটেশন।

vars বাইন্ডিং (request.vars)

vars বাইন্ডিং আপনার এক্সপ্রেশনগুলিকে আপনার কোয়েরি বা মিউটেশনে পাস করা সমস্ত ভেরিয়েবল অ্যাক্সেস করার অনুমতি দেয়।

আপনি সম্পূর্ণরূপে যোগ্যতাসম্পন্ন request.variables.<variablename> <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 বাঁধাই (request.auth)

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

আপনার ফিল্টার এবং এক্সপ্রেশনে, আপনি request.auth এর জন্য auth একটি উপনাম হিসেবে ব্যবহার করতে পারেন।

প্রমাণীকরণ বাইন্ডিংয়ে নিম্নলিখিত তথ্য রয়েছে:

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

auth.token এর বিষয়বস্তু সম্পর্কে আরও বিস্তারিত জানার জন্য auth টোকেনে ডেটা দেখুন।

response বাঁধাই

response বাইন্ডিং-এ সার্ভার কর্তৃক একত্রিত করা ডেটা থাকে যখন কোনও কোয়েরি বা মিউটেশনের প্রতিক্রিয়ায় সেই ডেটা একত্রিত করা হয় ।

ক্রিয়াকলাপটি এগিয়ে যাওয়ার সাথে সাথে, প্রতিটি ধাপ সফলভাবে সম্পন্ন হওয়ার সাথে সাথে, response সফলভাবে সম্পন্ন পদক্ষেপগুলি থেকে প্রতিক্রিয়া ডেটা থাকে।

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

মনে রাখবেন যে যখন আপনি এমবেডেড কোয়েরি রেসপন্স ডেটা অ্যাক্সেস করেন, তখন এম্বেডেড কোয়েরিতে অনুরোধ করা ডেটার উপর নির্ভর করে ফিল্ডগুলিতে যেকোনো ডেটা টাইপ থাকতে পারে; যখন আপনি _insert s এবং _delete s এর মতো মিউটেশন ফিল্ড দ্বারা ফেরত ডেটা অ্যাক্সেস করেন, তখন সেগুলিতে UUID কী, ডিলিটের সংখ্যা, নাল থাকতে পারে ( মিউটেশনের রেফারেন্স দেখুন)।

উদাহরণস্বরূপ:

• একটি এমবেডেড কোয়েরি ধারণকারী মিউটেশনের ক্ষেত্রে, response বাইন্ডিং-এ response.query.<fieldName>.<fieldName>.... -এ লুকআপ ডেটা থাকে, এই ক্ষেত্রে, response.query.todoList এবং response.query.todoList.priority ।

mutation CheckTodoPriority(
  $uniqueListName: String!
) {
  # This query is identified as `response.query`
  query @check(expr: "response.query.todoList.priority == 'high'", message: "This list is not for high priority items!") {
    # This field is identified as `response.query.todoList`
    todoList(where: { name: $uniqueListName }) {
      # This field is identified as `response.query.todoList.priority`
      priority
    }
  }
}

• একটি বহু-পদক্ষেপের মিউটেশনে, উদাহরণস্বরূপ একাধিক _insert ক্ষেত্রের সাথে, response বাইন্ডিংয়ে response.<fieldName>.<fieldName>.... , এই ক্ষেত্রে, response.todoList_insert.id ।

mutation CreateTodoListWithFirstItem(
  $listName: String!,
  $itemContent: String!
) @transaction {
  # Step 1
  todoList_insert(data: {
    id_expr: "uuidV4()",
    name: $listName,
  })
  # Step 2:
  todo_insert(data: {
    listId_expr: "response.todoList_insert.id" # <-- Grab the newly generated ID from the partial response so far.
    content: $itemContent,
  })
}

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 অথবা non- 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 নিরাপত্তা সম্পর্কে জানুন।