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

Support for Dynamic OpenAPI Specs ("servers": [{"url": "/"}]) #843

Closed
sennyeya opened this issue May 14, 2023 · 3 comments
Closed

Support for Dynamic OpenAPI Specs ("servers": [{"url": "/"}]) #843

sennyeya opened this issue May 14, 2023 · 3 comments

Comments

@sennyeya
Copy link

sennyeya commented May 14, 2023

Is your feature request related to a problem? Please describe.
Before I jump in, thanks for this library, it's really great! I'm working on adding OpenAPI request validation to Backstage and found this library. Basically, Backstage has a routing system that decouples the parent route from the plugin. Each plugin can be mounted at different routes for different implementations so a full Backstage spec has to be dynamic. See this.

To support that dynamic nature, each plugin has a spec with a

servers:
  - url: '/'

section (you can see an example here). Those specs can then be combined with routing knowledge at run time to create a tailored "Backstage" full API spec. However, my goal is to support per plugin validation that's decoupled from the full API spec. Plugin owners could then opt into validation and configure it themselves. Ideally, this library would be what we use for that. However, I'm getting issues from this line. The req.originalUrl will always contain the full URL with all of the parent routers, meaning it's not possible to validate against a router specific spec.

Describe the solution you'd like
A toggle to use req.path or req.url instead of req.originalUrl. Basically, the ability to turn off the functionality introduced in #211 to support fully context aware routers.

Describe alternatives you've considered
I also looked at #113, but I think this is a separate use case with a similar soluiton.

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

@nikkegg
Copy link
Contributor

nikkegg commented Aug 6, 2023

@cdimascio would you accept a PR for this? 🙏🏻

@cdimascio
Copy link
Owner

Yes. A PR for this is welcome. Thanks!

@cdimascio
Copy link
Owner

the new useRequestUrl option is available in v5.1.0. Set useRequestUrl: true in the validator options

See PR #857

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

3 participants