question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Question: How can we rely on specific fields in rules?

See original GitHub issue

Hello, first of all thanks for the great lib!

I have a a question. In docs there is a rule defined and used as:

const isOwner = rule()(async (parent, args, ctx, info) => {
  return ctx.user.items.some(id => id === parent.id)
})

const permissions = shield({
  /* ... */
  User: {
    secret: isOwner
  },
})

The rule uses parent.id which is ID of user to determine if the user is a owner. From what I’ve been able to understand by playing with this library, we can’t really rely on any field of parent.

Let’s say the client queries something like:

query {
  me {
    id
    secret
  }
}

Where me is a Query which returns current user - then everything is correct. However, what if client queries a Query:

query {
  me {
    # notice the missing ID
    secret
  }
}

then the parent.id in isOwner rule is undefined and we can’t correctly decide whether the user is owner or not.

How can the isOwner rule be implemented correctly? Is there even a way to do that?

Thanks!

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:10

github_iconTop GitHub Comments

7reactions
kratamcommented, Sep 11, 2018

Yes, thank you! For anyone else having the same problem, it should look like this:

const { fragmentReplacements, schema } = applyMiddleware(
  plainSchema,
  permissions,
)

// create transforms array for transformSchema
const transforms = [new ReplaceFieldWithFragment(schema, fragmentReplacements)]
// apply transformations
const finalSchema = transformSchema(schema, transforms)
5reactions
maticzavcommented, Jul 26, 2018

Hey @nemcek 👋

That’s an interesting question, and indeed you are right! The current version doesn’t support fragments. Fragments are a way of telling graphql resolver which information your resolver requires to work correctly.

The next version of shield should introduce this with the following syntax. Right now, we fully depend on graphql-tools PR and grpahql-middleware fragments support which should land in no time.

const nestedRule = rule({
  cache: 'strict',
  fragment: 'fragment UserID on User { id }',
})(async ({ id }, args, ctx, info) => {
  return somethingWithID(id)
})

I hope this covers your idea. Tell me if you have any thoughts on this as well! 🙂

Read more comments on GitHub >

github_iconTop Results From Across the Web

Question: How can we rely on specific fields in rules? #103
The rule uses parent.id which is ID of user to determine if the user is a owner. From what I've been able to...
Read more >
Using Conditions and Rules - Zengine
Field Rules or Conditional Rules allow you to show or hide a field based on a response to a previous field. This is...
Read more >
Guide to table relationships - Microsoft Support
You then provide Access with a way to bring the divided information back together — you do this by placing common fields in...
Read more >
Use dependent form fields - HubSpot Knowledge Base
Learn how to use dependent form fields to ask further qualifying questions based on previous answers.
Read more >
Is it possible to create firestore rules based on specific fields?
It's not possible to target specific fields like you are showing in security rules. You can only match whole documents with a match ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found