TriPSs
commented
4 days ago Just now saw the open questions, sorry.
Open Questions:
Where should the opt-in configuration be done? -- My feeling is in the resolver options
Would indeed say the resolver options (better naming is welcome):
{
resolvers: [{
create: {
one: { validateWithAuthFilter: true },
many: { validateWithAuthFilter: true },
validateWithAuthFilter: true // Enable for both
}
}]
}Where should the access be evaluated? -- The original implementation I had done implemented this in the typeorm-query-service however, given that we are evaluating the filters in JS we could move it to the resolver. My issue with that is I don't think this works very well with the assembler paradigm if you're CreateDTO is significantly different from core DTO/entity
Agree, where it is now is indeed the best.
nx-cloud[bot]
Following up on conversation here: https://github.com/TriPSs/nestjs-query/issues/320
When getting started with nestjs-query I found it un-intuitive that my authorizers would be executed during the creation flow, but then not evaluated in any way to prevent creation of resources that didn't match my auth criteria.
This PR allows users to opt in to having their authorization filters used when hitting creation end points.
Open Questions:
opt-inconfiguration be done? -- My feeling is in the resolver optionstypeorm-query-servicehowever, given that we are evaluating the filters inJSwe could move it to the resolver. My issue with that is I don't think this works very well with the assembler paradigm if you're CreateDTO is significantly different from core DTO/entity@TriPSs I'll start on test coverage once we're happy with the overall direction.