Context criteria and attributes are always empty objects

[bradisbell]

I am trying to figure out how to authenticate a request based on what Epilogue has determined the criteria are. I thought it would make sense to use the hooks and milestones for that.

The context object has criteria and attributes properties. While their functionality isn't documented, criteria is used in one of the code examples. I'm assuming that one of them is supposed to contain any query criteria as parsed from the request.

If I pass in a request for /streams?AccountId=1 (where AccountId is actually for an association to an Account model), I was hoping to be able to access this somewhere as Epilogue would use it in a query. While it is possible for me to pull this out of the query string on req myself, if I can validate the criteria Epilogue uses in its own query, I believe that would be a more reliable and secure implementation.

Is this possible today?

function tracer(req, res, context) {
  console.log('context', context);
  return context.continue();
}

rest.resource({
  model: orm.models.Stream,
  endpoints: ['/streams', '/streams/:id'],
  include: [ orm.models.Server ]

}).use({
  list: {
    start:  tracer,
    auth: tracer,
    fetch: tracer,
    data: tracer,
    write: tracer,
    send: tracer,
    complete: tracer
  }
});

[mbroadst]

@bradisbell all query items should be converted to search criteria in list: https://github.com/dchester/epilogue/blob/master/lib/Controllers/list.js#L88. There's actually a test that shows this off in particular: https://github.com/dchester/epilogue/blob/master/tests/resource/associations.test.js#L218. As you can see, for the list controller the criteria is built up as part of the fetch milestone so that might be the issue you are running into. I'm up or a discussion about how that preparation should happen earlier in the chain, if you have a proposal.

[bradisbell]

@mbroadst I'm not seeing anything in criteria in any milestone. Am I doing this correctly?

[mbroadst]

@bradisbell let's take the ListController for example here:

• context.criteria is used chiefly in the List.prototype.fetch milestone
• prior to this milestone the criteria can be modified, and will in turn be used in that milestone, but nothing explicitly sets any of the criteria
• If you look at that milestone, it saves off a copy of the criteria here, and then uses that criteria to fetch data from the database
• Since it modifies a local copy of the criteria, that's not going to show up in subsequent milestones either

In your provided example if you added something to context.criteria in e.g. the "start" milestone, you would see it in your traces:

.use({
  list: {
    start:  function(req, res, context) {
        context.criteria = { some: "criteria" }
        return context.continue();
    }
  }
});

So basically what I'm getting at is: this might not be the best behavior. Maybe we should pull off the criteria much earlier as a default milestone for these controllers (e.g. we move this to List.prototype.start or something). But we need to discuss it a bit first because these behavior changes, while undocumented, are depended upon by existing users

[bradisbell]

I think I understand what you are saying. The criteria is mainly for modification, and not for reading from. Is that correct?

[mbroadst]

@bradisbell context.criteria is used in that milestone to modify the query parameters, so in that way yes context.criteria is "for modification." However, I guess I'm pointing out that there is what might considered a bug here because the context.criteria is never updated in the milestone, so you wouldn't see any additional data in subsequent milestones. I'm not sure if I'm even answering your question anymore 😄

[mbroadst]

@bradisbell have we answered your question here?

[bradisbell]

I think so. At this point I have just written my own middleware for the specific routes that need the functionality I need. Thanks for the reply and explanation.