Links in LogEntryCollection are not followed and checked

Question

Links in LogEntryCollection are not followed and checked

jiaqingz-intel opened this issue 2 years ago · 8 comments

Version: 2.2.1

Validator only checks the LogEntry in the response payload of LogEntryCollection, the LogEntry resourced linked at @odata.id is not checked. (Response time is 0 and HTTP status is -1)

When the LogEntry resources at @odata.id is incorrect, as validator skips them, no error reported.

Answer 1 · 2022-10-17T08:33:29.000Z

~~Am I mistaken? The log is clearly showing a different payload. How is this happening in practice? I am confused.~~

Edit: Oh, nevermind. It is likely because the validator is not checking the DIRECT call to that odata.id, it is checking it from within the collection without GETting it from the service from it's URI twice (Note the 0ms response time).

I believe there's code in place for some URIs checked but not unique URIs like this. This is an assumption from the tool, and needs to be reported correctly.

Answer 2 · 2022-10-18T01:55:15.000Z

Edit: Oh, nevermind. It is likely because the validator is not checking the DIRECT call to that odata.id, it is checking it from within the collection without GETting it from the service from it's URI twice (Note the 0ms response time).

Oh I see, in other LogEntryCollection, it also does not follow the link.

I believe there's code in place for some URIs checked but not unique URIs like this. This is an assumption from the tool, and needs to be reported correctly.

I think only not following the links with # is the correct behavior, like this

Anyway I'm going to update the issue.

Answer 3 · 2023-04-07T21:37:57.000Z

I am also seeing this error. In validateURITree() of validateResource.py, it goes down the path if link.Type is not None and link.Type.AutoExpand because AutoExpand is set to true for LogEntry in the tool. And so it assumes the the collection it already got was auto-expanded, even though it did not request it to be expanded. So then it processes just the odata.id object in Members as if it were the full LogEntry resource and complains that it is missing every field except odata.id.

Answer 4 · 2023-04-08T13:59:55.000Z

The collection is supposed to be expanded even if not requested; if LogEntryCollection does not show the contents of the LogEntry resources in the Members array, it's nonconformant.

Answer 5 · 2023-04-08T16:50:27.000Z

@blakehilliard to be clear, are you saying the collection is auto expanded and the case is it's treating it like it's not? Do you have a sample of what you're running exactly from the command line?

Answer 6 · 2023-04-11T14:54:44.000Z

Thanks, I was unaware a collection could have thiis auto-expansion requirement.

Answer 7 · 2023-04-11T16:10:42.000Z

To date, we only have that requirement on the LogEntryCollection (with the OData.AutoExpand term specified on the Members NavigationProperty). In theory it could be applied elsewhere, but there hasn't been a need to force expansion like with logs. The service validator dynamically looks for the OData.AutoExpand term to determine whether or not it should expect the expansion in the response (and validates accordingly).