Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

validation since 5.2.2 is broken because of [id] field #458

Closed
eugene-matvejev opened this issue Oct 16, 2017 · 3 comments
Closed

validation since 5.2.2 is broken because of [id] field #458

eugene-matvejev opened this issue Oct 16, 2017 · 3 comments

Comments

@eugene-matvejev
Copy link

eugene-matvejev commented Oct 16, 2017

Hello guys, I noticed that with 5.2.2 validation is broken, if ID field is present.

I made side project to demonstrate issue:
Working: eugene-matvejev/symfony-battleship#754
Broken: eugene-matvejev/symfony-battleship#755

json schemas:
https://github.com/eugene-matvejev/battleship-game-api-json-schema

output

tests:behat:
    [behat] ..............F
    [behat] 
    [behat] --- Failed steps:
    [behat] 
    [behat] 001 Example: | POST   | /api/game-init           | game.init.request.1.opponent.json | game.init.response.schema.json    | # tests/behat/suites/api/api.json.validation.against.schema.feature:11
    [behat]       Then validate response against schema "game.init.response.schema.json"                                               # tests/behat/suites/api/api.json.validation.against.schema.feature:7
    [behat]         Unable to resolve URI 'properties/collection' from base '' (JsonSchema\Exception\UriResolverException)
    [behat] 
    [behat] 6 scenarios (5 passed, 1 failed)
    [behat] 15 steps (14 passed, 1 failed)
    [behat] 0m0.39s (22.07Mb)
@erayd
Copy link
Contributor

erayd commented Oct 16, 2017

Thanks for reporting this. However, the current release is 5.2.5 (not 5.2.2), and fixes some known bugs relating to id / $ref.

Do you still encounter this problem with v5.2.5?

@erayd
Copy link
Contributor

erayd commented Oct 17, 2017

@eugene-matvejev I've tested your project with 5.2.5, and can confirm I have replicated the issue within that project.

Could you please post a minimal test case that illustrates where you are encountering this, rather than an entire project?

erayd added a commit to erayd/json-schema that referenced this issue Oct 17, 2017
@erayd
Copy link
Contributor

erayd commented Oct 17, 2017

I have now pinpointed the root cause of this problem.

  1. You are loading a schema without a provided URI.
  2. Because of (1), the default of `internal://provided-schema' is used.
  3. You are then attempting to set a relative id of `properties/collection'.
  4. The internal default does not contain a path section, and throws an exception when trying to resolve (3) against it.

This is fixed in #459, and I will backport it for 5.2.6 once merged. I can confirm this fix resolves the issue in your project.

In the meantime, if you add any arbitrary id URI to the top level of your schema document, it will work properly, provided that URI contains a path element.

Note also that your use of the id keyword is extremely strange - you seem to be identifying an awful lot of stuff, but in a way that does not result in a valid location if you were to try dereferencing it. What goal are you trying to achieve with your use of id in those schema documents?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants