Changing the resolution base via 'id' does not work properly #447

erayd · 2017-09-21T09:24:44Z

Per issue #446. See below test case:

$data = json_decode(<<<'eot'
{
    "propertyOne": "blue"
}
eot
);

$base = json_decode(<<<'eot'
{
    "id": "schema.json",
    "properties": {
        "propertyOne": {
            "$ref": "propertyOne.json"
        }
    }
}
eot
);

$validator = new \JsonSchema\Validator();
var_dump($validator->validate($data, $base));

@bighappyface Could you please mark this as blocking for 6.0.0? I need to stare at the code some more, but at first look this may require significant refactoring of the $ref code.

The text was updated successfully, but these errors were encountered:

erayd · 2017-09-21T22:38:25Z

@shmax Have you had anything to do with with the ref processing when the scope has been changed? Some insight into how this is intended to work would be handy and would save a lot of time tracing stuff. No worries if not.

The tests in draft4/refRemote.json all pass, including the ones with a nested scope change (e.g. folderInteger.json), but the logic that actually achieves this isn't clear, and it's not covering all cases. In the test code above, the resolution base gets completely dropped somewhere along the line, despite being explicitly set in the base schema.

shmax · 2017-09-21T22:50:07Z

No, not only was that before my time, but I never really totally figured out how to get $ref functionality working in my own code; I had to resort to overriding the UriResolver and just cheeseballing the resolve method. I looked over this issue, but I think I'm a bit out of my depth; I don"t even know what a "behat" is. I'll see if I can get caught up a bit more this weekend.

erayd · 2017-09-21T22:55:22Z

Bugger. Will get to tracing stuff then. Thanks anyway :-).

erayd · 2017-09-21T22:59:37Z

For what it's worth, this bug has nothing to do with Behat. Behat just happens to depend on this validator, and @dkarlovi happened to find the bug while using Behat.

shmax · 2017-09-21T23:05:52Z

Gotcha. I'll load up his sample app tomorrow and see if I can make any sense of it.

erayd · 2017-09-21T23:10:30Z

No need, unless you're curious - the test case at the top of this thread reproduces the bug using only the json-schema validator.

dkarlovi · 2017-09-22T05:54:08Z

Behat is irrelevant here, I used it to replicate the bug the only way I knew how. :)

mdeboer · 2017-09-27T20:16:05Z

Same problem here and I have no clue how to get it to work except for writing my own resolver I guess. Can't we just add a getter/setter for the base path for the resolver? This would make all relative file references relative to that path.

I can probably cook something up but I'm not sure if it would break stuff as this is a bug apparently.

erayd · 2017-09-27T20:21:40Z

@mdeboer This is definitely a bug. I will fix it.

Regarding your suggestion of a base path setter... what purpose would this serve? The spec already defines the id keyword as filling this role; it's just the implementation which is broken.

mdeboer · 2017-09-27T20:26:19Z

Alright, awaiting the fix then 👍

Fixes jsonrainbow#447 Note that this patch does not check whether a given container is actually a schema when recursing into it. In most cases this will not matter, however it does mean that in some edge cases it will attempt to resolve a `$ref` in a context where ref is actually not part of the spec. Limiting resolution to schema-context containers is outside the scope of this patch, but can be added later.

erayd · 2017-09-30T03:41:21Z

@mdeboer See #448. Assuming code review is OK, I will backport this fix to 5.x.x after merge.

Fixes jsonrainbow#447 Note that this patch does not check whether a given container is actually a schema when recursing into it. In most cases this will not matter, however it does mean that in some edge cases it will attempt to resolve a `$ref` in a context where ref is actually not part of the spec. Limiting resolution to schema-context containers is outside the scope of this patch, but can be added later.

dkarlovi · 2017-10-02T12:59:23Z

@erayd is this actually backward compatible, will it even land in 5.x?

erayd · 2017-10-02T18:05:23Z

@dkarlovi Yes. I very deliberately implemented it in a manner that could be backported to 5.x.x without breaking anything.

dkarlovi · 2017-10-02T18:27:58Z

@erayd great, looking forward to seeing it released, thanks!

Fixes jsonrainbow#447 Note that this patch does not check whether a given container is actually a schema when recursing into it. In most cases this will not matter, however it does mean that in some edge cases it will attempt to resolve a `$ref` in a context where ref is actually not part of the spec. Limiting resolution to schema-context containers is outside the scope of this patch, but can be added later.

Fixes #447 Note that this patch does not check whether a given container is actually a schema when recursing into it. In most cases this will not matter, however it does mean that in some edge cases it will attempt to resolve a `$ref` in a context where ref is actually not part of the spec. Limiting resolution to schema-context containers is outside the scope of this patch, but can be added later.

Fixes jsonrainbow#447 Note that this patch does not check whether a given container is actually a schema when recursing into it. In most cases this will not matter, however it does mean that in some edge cases it will attempt to resolve a `$ref` in a context where ref is actually not part of the spec. Limiting resolution to schema-context containers is outside the scope of this patch, but can be added later.

erayd · 2017-10-03T00:46:36Z

@dkarlovi Now backported for 5.2.2 - see PR #450.

* Update php-csfixer rules to address problem in 2.7 & new multiline rule (#449) * Update php-csfixer rules to address problem in 2.7 & new multiline rule * yoda_style in 2.7 is dangerous and may result in logic errors. In some cases, it also results in invalid syntax. * multiline comments prefixed with // now seem to be misaligned, and this cannot be disabled, so have changed the relevant comment. * PHP-5.3 is not available on trusty, so explicitly specify precise for 5.3 * Add proper recursive handling for $ref resolution base (#448) Fixes #447 Note that this patch does not check whether a given container is actually a schema when recursing into it. In most cases this will not matter, however it does mean that in some edge cases it will attempt to resolve a `$ref` in a context where ref is actually not part of the spec. Limiting resolution to schema-context containers is outside the scope of this patch, but can be added later.

erayd mentioned this issue Sep 21, 2017

[Question] local relative $ref #446

Closed

erayd mentioned this issue Oct 3, 2017

Backports for 5.2.2 (Part 3) #450

Merged

erayd closed this as completed Oct 10, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Changing the resolution base via 'id' does not work properly #447

Changing the resolution base via 'id' does not work properly #447

erayd commented Sep 21, 2017 •

edited

erayd commented Sep 21, 2017

shmax commented Sep 21, 2017

erayd commented Sep 21, 2017

erayd commented Sep 21, 2017

shmax commented Sep 21, 2017

erayd commented Sep 21, 2017

dkarlovi commented Sep 22, 2017

mdeboer commented Sep 27, 2017

erayd commented Sep 27, 2017

mdeboer commented Sep 27, 2017

erayd commented Sep 30, 2017

dkarlovi commented Oct 2, 2017

erayd commented Oct 2, 2017

dkarlovi commented Oct 2, 2017

erayd commented Oct 3, 2017

Changing the resolution base via 'id' does not work properly #447

Changing the resolution base via 'id' does not work properly #447

Comments

erayd commented Sep 21, 2017 • edited

erayd commented Sep 21, 2017

shmax commented Sep 21, 2017

erayd commented Sep 21, 2017

erayd commented Sep 21, 2017

shmax commented Sep 21, 2017

erayd commented Sep 21, 2017

dkarlovi commented Sep 22, 2017

mdeboer commented Sep 27, 2017

erayd commented Sep 27, 2017

mdeboer commented Sep 27, 2017

erayd commented Sep 30, 2017

dkarlovi commented Oct 2, 2017

erayd commented Oct 2, 2017

dkarlovi commented Oct 2, 2017

erayd commented Oct 3, 2017

erayd commented Sep 21, 2017 •

edited