User story. As an API mock tester, when I startup PRISM and my OpenAPI spec contains an unresolvable $ref, then I want to receive a notification, so that I can try to fix the problem without having to try to fire that request against the mock by myself.

Is your feature request related to a problem? i have tried to get started with PRISM and I have a spec with DTO models externalized into a separate file. My spec is affected by bug #390. If you experiment with the $refs, you need to try some calls before you know if it works or not. [15:43:16] » [CLI] ► start Prism is listening on http://127.0.0.1:4010 (...) I'm firing a call manually with Postman (...) [15:43:38] » [NEGOTIATOR] √ success Found a compatible content for */* (node:10040) UnhandledPromiseRejectionWarning: Error: Your schema contains $ref. You must provide specification in the third parameter.

Describe the solution you'd like During startup, Prism tries to resolve the $refs and outputs a warning if calls use unresolvable $refs.

Additional context Go with a "Fail fast" approach

Hello,

Thanks you guys for creating this. It's very helpful for mocking and creating apis.

Do you think it would be possible to add a command line arg, to define how much data is sent by the api ? This would be very helpful when we need some endpoint to return more than just one to 3 lines...

thanks in advance.

Describe the bug

A clear and concise description of what the bug is. Pointing prism to a file that contains components that use recursive field definition, Prism fails with the message:

Circular $ref pointer found at /tmp/test.yaml#/components/schemas/Person/properties/spouse

To Reproduce

A minimal API definition triggering the error message:

info:
  title: "Circular reference example"
  description: "Exemplifies a schema with circular references"
  version: 0.1.0

paths:
  /directory:
    get:
      responses:
        "200":
          description: "The request was successfully processed"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Person"
              example:
                name: John
                spouse:
                  name: Cynthia

components:

  schemas:

    Person:
      nullable: true
      properties:
        name:
          type: string
          nullable: false
        spouse:
          $ref: "#/components/schemas/Person"

Expected behavior

As the OAS file specifies a valid API, the server should be able to mock that API. While having a circular reference can theoretically lead to a infinite recursion, this can be in practice avoided by having a nullable reference to the child object.

Environment

• Prism version: [4.1.0]

I have a simple DELETE endpoint and want to return empty with a 204

Documentation says

"Some responses, such as 204 No Content, have no body. To indicate the response body is empty, do not specify a content for the response"

https://swagger.io/docs/specification/describing-responses/

 /api/calls/{id}:
    delete: # DELETE
      tags:
        - Calls
      description: Delete a call history item
      parameters:
        - $ref: '#/components/parameters/id'
      responses:
        204:
          description: OK
        400:
          description: NOK
        500:
          description: ERROR
components:
    id:
      in: path
      name: id
      description: id for the item
      required: true
      schema:
        type: integer
        format: int64

curl -X DELETE "http://127.0.0.1:4010/api/calls/1" -H "accept: */*"
or
curl -X DELETE "http://127.0.0.1:4010/api/calls/1"  

{
detail: "Unable to find content for application/json, text/plain, */*"
status: 406
title: "The server cannot produce a representation for your accept header"
type: "https://stoplight.io/prism/errors#NOT_ACCEPTABLE"        
}   

The following is a workaround but it seems like it is pollution in my spec file

  /api/calls/{id}:
    delete: # DELETE
      tags:
        - Calls
      description: Delete a call history item
      parameters:
        - $ref: '#/components/parameters/id'
      responses:
        204:
          description: OK
          content:
            '*/*':
              schema:
                type: string
        400:
          description: NOK
        500:
          description: ERROR

Describe the bug I use Postman (https://www.postman.com/) with Prism, with good results. When I put Prism into proxy mode, Postman thinks it didn't get a response (but curl to the same endpoint works fine).

Prism shows no error messages, the output from Prism is identical whether I make the request through Postman or curl

Postman's console says "incorrect header check"

curl shows that Prism is returning a header content-encoding: gzip, which I don't get when I request the live API directly rather than via the Prism proxy.

To Reproduce

1. Given this OpenAPI document (actually I'm not sure it matters but I'm using https://github.com/Nexmo/api-specification/blob/master/definitions/verify.yml and hitting the search/ endpoint
2. Run this CLI command prism proxy verify.yml https://api.nexmo.com/verify
3. Make a request to the Search endpoint using Postman

Expected behavior The API response

Environment (remove any that are not applicable):

• Library version: 3.2.9
• OS: Ubuntu 18.04
• Postman 7.21.1
• curl: 7.58.0

Additional context I managed to get things working by adding an additional header to Postman Accept-Encoding and leaving it empty - I think Postman sends this header by default. However curl does not send Accept-Encoding by default and I still see that Prism returns a content-encoding: gzip to curl so while I'm not sure Postman is sending correct headers, I think Prism is also adding something here that doesn't help!

User story.

As a dev, I can do run proxy getting real values from upstream when a route has been implemented upstream, and mocked values when a route has not been implemented upstream, so that I can get the best of both worlds.

Is your feature request related to a problem?

I'd like to get real data as soon as it's available, but also continue to get mocked data for routes that are not yet implemented.

Describe the solution you'd like

When upstream returns 501 (not implemented), prism behaves as it does in mock mode. Else, it behaves as in proxy mode.

Additional context

Add any other context or screenshots about the feature request here.

Describe the bug

Hello! I could really use some help and guidance!

I have an Open API spec that is valid when I used Spectral

I can successfully run it with Prism

I have unit tests that validate an endpoint, so I am using Prism like so prism proxy --errors example.yaml http://localhost:8080

When I send an invalid request it keeps giving me this error

{
  type: 'https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY',
  title: 'Invalid request',
  status: 422,
  detail: 'Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you.',
  validation: [
    {
      location: [Array],
      severity: 'Error',
      code: 'required',
      message: "should have required property 'firstname'"
    },
    {
      location: [Array],
      severity: 'Error',
      code: 'required',
      message: "should have required property 'lastname'"
    },
    {
      location: [Array],
      severity: 'Error',
      code: 'required',
      message: "should have required property 'email'"
    },
    {
      location: [Array],
      severity: 'Error',
      code: 'required',
      message: "should have required property 'password'"
    }
  ]
}

Which is wild because this DOES exist.

It keeps stating Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you which is not true at all because I have a 422 response declared for the endpoint that's being hit!

I have tried setting a 400 response. I've tried setting different data for the response. And nothing is working.

What am I doing wrong?

To Reproduce

Use this file

---
openapi: '3.0.2'

servers:
    - url: http://localhost:8080
      description: Local deployment from your computer

paths:
    /api/users/register:
        post:
            summary: 'Register New User'
            description: 'Register a new user'
            operationId: 'registerNewUser'
            tags: ['Users']
            requestBody:
                required: true
                content:
                    application/json:
                        schema:
                            type: 'object'
                            properties:
                                firstname:
                                    type: 'string'
                                    minLength: 2
                                    maxLength: 100
                                    example: 'John'
                                lastname:
                                    type: 'string'
                                    minLength: 2
                                    maxLength: 100
                                    example: 'Roberts'
                                email:
                                    type: 'string'
                                    minLength: 4
                                    maxLength: 100
                                    example: '[email protected]'
                                password:
                                    type: 'string'
                                    minLength: 8
                                    maxLength: 50
                                    example: 'abc123456'
                            required:
                                - firstname
                                - lastname
                                - email
                                - password
            responses:
                '201':
                    description: Successful registration of a new user
                '422':
                    description: Failed to register new user
                    content:
                        application/json:
                            schema:
                                type: 'object'
                                properties:
                                    message:
                                        type: 'string'
                                        example: 'firstname is required'

Run prism proxy --errors example.yaml http://localhost:8080

Run this curl command to confirm it works

curl --location --request POST 'localhost:4010/api/users/register' \
--header 'Content-Type: application/json' \
--data-raw '{
	"firstname": "First",
	"lastname": "Last",
	"email": "[email protected]",
	"password": "This_is_4_str0ng_password!"
}'

If you want pretty printing you can add json_pp

curl --location --request POST 'localhost:4010/api/users/register' \
--header 'Content-Type: application/json' \
--data-raw '{
	"firstname": "First",
	"lastname": "Last",
	"email": "[email protected]",
	"password": "This_is_4_str0ng_password!"
}'

Run this command to confirm it fails

curl --location --request POST 'localhost:4010/api/users/register' \
--header 'Content-Type: application/json' \
--data-raw '{}'

Same, but with pretty printing

curl --location --request POST 'localhost:4010/api/users/register' \
--header 'Content-Type: application/json' \
--data-raw '{}' | json_pp

And the final output is this

~/Repositories/example   feature/api_spec_and_test_reconciliation ±  ⬡ v12.17.0  curl --location --request POST 'localhost:4010/api/users/register' \
--header 'Content-Type: application/json' \
--data-raw '{}' | json_pp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   702  100   700  100     2   113k    333 --:--:-- --:--:-- --:--:--  114k
{
   "detail" : "Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you.",
   "title" : "Invalid request",
   "type" : "https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY",
   "status" : 422,
   "validation" : [
      {
         "severity" : "Error",
         "location" : [
            "body"
         ],
         "message" : "should have required property 'firstname'",
         "code" : "required"
      },
      {
         "message" : "should have required property 'lastname'",
         "location" : [
            "body"
         ],
         "severity" : "Error",
         "code" : "required"
      },
      {
         "code" : "required",
         "severity" : "Error",
         "location" : [
            "body"
         ],
         "message" : "should have required property 'email'"
      },
      {
         "message" : "should have required property 'password'",
         "location" : [
            "body"
         ],
         "severity" : "Error",
         "code" : "required"
      }
   ]
}

Expected behavior

I expect the responses I created for 422 to be used so that I don't have to worry about Prism returning different payloads than what my server does.

Questions

How do I get Prism to not return a generated 422 override?

Because it keeps generating that validation response I can't integrate it with my tests, because the tests expect a message property to be there.

I've read through the documentation here:

• https://meta.stoplight.io/docs/prism/docs/guides/errors.md#unprocessable_entity
• https://meta.stoplight.io/docs/prism/docs/guides/02-request-validation.md#request-validation

And none of it provides an explicit example on how to make it so that Prism does not return an auto-generated response.

Additional context

• Prism: 4.1.2
• OS: MacOS

User story. As a frontend developer, I want to connect to the local mock server, so that I can see mocked responses in my browser.

Is your feature request related to a problem? I can not connect to the mock server via a secure browser, as the CORS Headers are not set up correctly to allow any origin and any verb (OPTIONS, GET, POST, PATCH, etc.)

Describe the solution you'd like The stoplight client mock server is sending out widely set CORS headers to allow any origin and any verb - or it allows me to configure it myself.

Additional context

Closes #591

Checklist

• [x] Tests have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

Bug fix.

What is the current behavior? What is the new behavior?

The order of finding a response for an invalid request is now changed from: 422, 400, 401, 403, 422 (.default) to: 401, 403, 422, 400, 422 (.default) 401 and 403 are only checked for if there were security issues

Does this PR introduce a breaking change?

No.

Checklist

• [x] Tests have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce?

Feature

Programatically extend JSON Schema Faker options, formats and keywords.

The provided solution implemented in #384 is not sufficient for certain use-cases.

Eg. Generated HTML, localized Faker support, custom functions, etc.

The goal is to be as randomly realistic to the production API as possible.

What is the current behavior? What is the new behavior?

The new behaviour allows custom JSON Schema Faker options, formats and keywords to be added when using the Prism mocking server programmatically.

The OpenAPI spec allow custom formats for the properties with the type string and custom keywords using extensions

Example: mocking-server.js

const { createServer } = require("@stoplight/prism-http-server");
const { createLogger } = require("@stoplight/prism-core");
const minimist = require("minimist");
const { loremIpsum } = require("lorem-ipsum");
const Chance = require('chance');


const { port = 3001, schema: path } = minimist(process.argv);

const JSONSchemaFakerConfig = {
  options: {
    // Available options: https://github.com/json-schema-faker/json-schema-faker/tree/master/docs#available-options
    maxItems: 100,
  },

  // https://github.com/json-schema-faker/json-schema-faker/blob/master/docs/USAGE.md#custom-formats
  customFormats: {
    html: loremIpsum({
      count: 5,
      format: "plain",
      units: "paragraphs"
    });
  },

  // https://github.com/json-schema-faker/json-schema-faker/blob/master/docs/USAGE.md#extending-dependencies
  extensions: {
    chance: () => {
      const chance = new Chance();

      chance.mixin({
        user: () => {
          const first = chance.first();
          const last = chance.last();
          const email = chance.email();
          return `${first} ${last} – ${email}`;
        }
      });

      return chance;
    }
  }
}

const server = createServer(
  { path },
  {
    config: { mock: { dynamic: JSONSchemaFakerConfig } },
    components: {
      logger: createLogger()
    }
  }
);

server.listen(port).then(() => {
  console.log(`🤖 Mocking server enabled on port ${port}`);
});

Does this PR introduce a breaking change?

No.

When my requisition is with a header, the response is a 422, saying Missing Authorization Header param, but i put in the requisition -H "Authorization: bearer blabla". Is that an issue? When i use the Authorization as query, it works

Bumps @typescript-eslint/eslint-plugin from 2.34.0 to 5.48.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps eslint-config-prettier from 7.2.0 to 8.6.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Context

I was hoping to try out the mock behavior, but the lack of actionable error messages frustrated me and made me look elsewhere

Current Behavior

I used the docker getting started guide copying the command and providing the openapi URL:

$ docker run --init -p 4010:4010 stoplight/prism:4 mock -h 0.0.0.0 https://raw.githubusercontent.com/okta/okta-sdk-java/okta-sdk-root-10.0.0/src/swagger/api.yaml
[2:23:10 AM] › [CLI] …  awaiting  Starting Prism…
[2:23:13 AM] › [CLI] ✖  fatal     Token "definitions" does not exist.

I am completely open to that file being invalid OpenAPI according to some definition of invalid, but the tool does not tell me that. Also, I made sure that a copy of Insomnia could actually import it, meaning it was valid for some definition

Expected Behavior

Of course, the ultimate expected behavior is that it parses the provided file and generates stubs for its endpoints, but this specific bug is because

Token "definitions" does not exist.

does not offer the user any action to take; there are 14 mentions of definitions in that file, and the software is currently angry at one of them, but does not say which one

Possible Workaround/Solution

Steps to Reproduce

1. Execute the console command above
2. Observe the error

Environment

• Version used: "stoplight/[email protected]:0f582c33a702bbdfc1d47b43f9856ae98b943b2fe54d2265b1cfb37291e5435e" which is the current :4 as of this bug

• Environment name and version (e.g. Chrome 39, node.js 5.4): the image has "NODE_VERSION=16.17.1" in its environment

• Operating System and version (desktop or mobile): desktop

• Link to your environment/workspace/project: see above

Bumps qs from 6.5.2 to 6.5.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps chalk from 4.1.2 to 5.2.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.