Explorar el Código

Change Swagger-UI -> Swagger UI in docs (#5479)

* Change Swagger-UI -> Swagger UI in docs

* Changed back to SwaggerUI in places that refer to JS construct
bubble
Helen Kosova hace 5 años
committed by Ron
padre
commit
8822a7229a
Se han modificado 15 ficheros con 77 adiciones y 77 borrados
  1. +2
    -2
      docs/README.md
  2. +1
    -1
      docs/book.json
  3. +2
    -2
      docs/customization/custom-layout.md
  4. +7
    -7
      docs/customization/overview.md
  5. +4
    -4
      docs/customization/plug-points.md
  6. +9
    -9
      docs/customization/plugin-api.md
  7. +2
    -2
      docs/development/scripts.md
  8. +2
    -2
      docs/development/setting-up.md
  9. +18
    -18
      docs/usage/configuration.md
  10. +6
    -6
      docs/usage/cors.md
  11. +7
    -7
      docs/usage/deep-linking.md
  12. +4
    -4
      docs/usage/installation.md
  13. +1
    -1
      docs/usage/limitations.md
  14. +2
    -2
      docs/usage/oauth2.md
  15. +10
    -10
      docs/usage/version-detection.md

+ 2
- 2
docs/README.md Ver fichero

@@ -1,5 +1,5 @@
# Swagger-UI
# Swagger UI

Welcome to the Swagger-UI documentation!
Welcome to the Swagger UI documentation!

A table of contents can be found at `SUMMARY.md`.

+ 1
- 1
docs/book.json Ver fichero

@@ -1,3 +1,3 @@
{
"title": "Swagger-UI"
"title": "Swagger UI"
}

+ 2
- 2
docs/customization/custom-layout.md Ver fichero

@@ -1,8 +1,8 @@
# Creating a custom layout

**Layouts** are a special type of component that Swagger-UI uses as the root component for the entire application. You can define custom layouts in order to have high-level control over what ends up on the page.
**Layouts** are a special type of component that Swagger UI uses as the root component for the entire application. You can define custom layouts in order to have high-level control over what ends up on the page.

By default, Swagger-UI uses `BaseLayout`, which is built into the application. You can specify a different layout to be used by passing the layout's name as the `layout` parameter to Swagger-UI. Be sure to provide your custom layout as a component to Swagger-UI.
By default, Swagger UI uses `BaseLayout`, which is built into the application. You can specify a different layout to be used by passing the layout's name as the `layout` parameter to Swagger UI. Be sure to provide your custom layout as a component to Swagger UI.

<br>



+ 7
- 7
docs/customization/overview.md Ver fichero

@@ -2,7 +2,7 @@

### Prior art

Swagger-UI leans heavily on concepts and patterns found in React and Redux.
Swagger UI leans heavily on concepts and patterns found in React and Redux.

If you aren't already familiar, here's some suggested reading:

@@ -17,7 +17,7 @@ In the following documentation, we won't take the time to define the fundamental

### The System

The _system_ is the heart of the Swagger-UI application. At runtime, it's a JavaScript object that holds many things:
The _system_ is the heart of the Swagger UI application. At runtime, it's a JavaScript object that holds many things:

- React components
- Bound Redux actions and reducers
@@ -27,11 +27,11 @@ The _system_ is the heart of the Swagger-UI application. At runtime, it's a Java
- References to the React and Immutable.js libraries (`system.React`, `system.Im`)
- User-defined helper functions

The system is built up when Swagger-UI is called by iterating through ("compiling") each plugin that Swagger-UI has been given, through the `presets` and `plugins` configuration options.
The system is built up when Swagger UI is called by iterating through ("compiling") each plugin that Swagger UI has been given, through the `presets` and `plugins` configuration options.

### Presets

Presets are arrays of plugins, which are provided to Swagger-UI through the `presets` configuration option. All plugins within presets are compiled before any plugins provided via the `plugins` configuration option. Consider the following example:
Presets are arrays of plugins, which are provided to Swagger UI through the `presets` configuration option. All plugins within presets are compiled before any plugins provided via the `plugins` configuration option. Consider the following example:

```javascript
const MyPreset = [FirstPlugin, SecondPlugin, ThirdPlugin]
@@ -43,7 +43,7 @@ SwaggerUI({
})
```

By default, Swagger-UI includes the internal `ApisPreset`, which contains a set of plugins that provide baseline functionality for Swagger-UI. If you specify your own `presets` option, you need to add the ApisPreset manually, like so:
By default, Swagger UI includes the internal `ApisPreset`, which contains a set of plugins that provide baseline functionality for Swagger UI. If you specify your own `presets` option, you need to add the ApisPreset manually, like so:

```javascript
SwaggerUI({
@@ -54,7 +54,7 @@ SwaggerUI({
})
```

The need to provide the `apis` preset when adding other presets is an artifact of Swagger-UI's original design, and will likely be removed in the next major version.
The need to provide the `apis` preset when adding other presets is an artifact of Swagger UI's original design, and will likely be removed in the next major version.

### getComponent

@@ -62,7 +62,7 @@ The need to provide the `apis` preset when adding other presets is an artifact o

All components should be loaded through `getComponent`, since it allows other plugins to modify the component. It is preferred over a conventional `import` statement.

Container components in Swagger-UI can be loaded by passing `true` as the second argument to `getComponent`, like so:
Container components in Swagger UI can be loaded by passing `true` as the second argument to `getComponent`, like so:

```javascript
getComponent("ContainerComponentName", true)


+ 4
- 4
docs/customization/plug-points.md Ver fichero

@@ -1,16 +1,16 @@
# Plug points

Swagger-UI exposes most of its internal logic through the plugin system.
Swagger UI exposes most of its internal logic through the plugin system.

Often, it is beneficial to override the core internals to achieve custom behavior.

### Note: Semantic Versioning

Swagger-UI's internal APIs are _not_ part of our public contract, which means that they can change without the major version changing.
Swagger UI's internal APIs are _not_ part of our public contract, which means that they can change without the major version changing.

If your custom plugins wrap, extend, override, or consume any internal core APIs, we recommend specifying a specific minor version of Swagger-UI to use in your application, because they will _not_ change between patch versions.
If your custom plugins wrap, extend, override, or consume any internal core APIs, we recommend specifying a specific minor version of Swagger UI to use in your application, because they will _not_ change between patch versions.

If you're installing Swagger-UI via NPM, for example, you can do this by using a tilde:
If you're installing Swagger UI via NPM, for example, you can do this by using a tilde:

```js
{


+ 9
- 9
docs/customization/plugin-api.md Ver fichero

@@ -1,14 +1,14 @@
# Plugins

A plugin is a function that returns an object - more specifically, the object may contain functions and components that augment and modify Swagger-UI's functionality.
A plugin is a function that returns an object - more specifically, the object may contain functions and components that augment and modify Swagger UI's functionality.

### Note: Semantic Versioning

Swagger-UI's internal APIs are _not_ part of our public contract, which means that they can change without the major version changing.
Swagger UI's internal APIs are _not_ part of our public contract, which means that they can change without the major version changing.

If your custom plugins wrap, extend, override, or consume any internal core APIs, we recommend specifying a specific minor version of Swagger-UI to use in your application, because they will _not_ change between patch versions.
If your custom plugins wrap, extend, override, or consume any internal core APIs, we recommend specifying a specific minor version of Swagger UI to use in your application, because they will _not_ change between patch versions.

If you're installing Swagger-UI via NPM, for example, you can do this by using a tilde:
If you're installing Swagger UI via NPM, for example, you can do this by using a tilde:

```js
{
@@ -96,7 +96,7 @@ Once an action has been defined, you can use it anywhere that you can get a syst
system.exampleActions.updateFavoriteColor("blue")
```

The Action interface enables the creation of new Redux action creators within a piece of state in the Swagger-UI system.
The Action interface enables the creation of new Redux action creators within a piece of state in the Swagger UI system.

This action creator function will be exposed to container components as `exampleActions.updateFavoriteColor`. When this action creator is called, the return value (which should be a [Flux Standard Action](https://github.com/acdlite/flux-standard-action)) will be passed to the `example` reducer, which we'll define in the next section.

@@ -225,7 +225,7 @@ A Wrap Action's first argument is `oriAction`, which is the action being wrapped
This mechanism is useful for conditionally overriding built-in behaviors, or listening to actions.

```javascript
// FYI: in an actual Swagger-UI, `updateSpec` is already defined in the core code
// FYI: in an actual Swagger UI, `updateSpec` is already defined in the core code
// it's just here for clarity on what's behind the scenes
const MySpecPlugin = function(system) {
return {
@@ -251,9 +251,9 @@ const MyWrapActionPlugin = function(system) {
spec: {
wrapActions: {
updateSpec: (oriAction, system) => (str) => {
// here, you can hand the value to some function that exists outside of Swagger-UI
// here, you can hand the value to some function that exists outside of Swagger UI
console.log("Here is my API definition", str)
return oriAction(str) // don't forget! otherwise, Swagger-UI won't update
return oriAction(str) // don't forget! otherwise, Swagger UI won't update
}
}
}
@@ -273,7 +273,7 @@ This interface is useful for controlling what data flows into components. We use
```javascript
import { createSelector } from 'reselect'

// FYI: in an actual Swagger-UI, the `url` spec selector is already defined
// FYI: in an actual Swagger UI, the `url` spec selector is already defined
// it's just here for clarity on what's behind the scenes
const MySpecPlugin = function(system) {
return {


+ 2
- 2
docs/development/scripts.md Ver fichero

@@ -6,11 +6,11 @@ Any of the scripts below can be run by typing `npm run <script name>` in the pro
Script name | Description
--- | ---
`dev` | Spawn a hot-reloading dev server on port 3200.
`deps-check` | Generate a size and licensing report on Swagger-UI's dependencies.
`deps-check` | Generate a size and licensing report on Swagger UI's dependencies.
`lint` | Report ESLint style errors and warnings.
`lint-errors` | Report ESLint style errors, without warnings.
`lint-fix` | Attempt to fix style errors automatically.
`watch` | Rebuild the core files in `/dist` when the source code changes. Useful for `npm link` with Swagger-Editor.
`watch` | Rebuild the core files in `/dist` when the source code changes. Useful for `npm link` with Swagger Editor.

### Building
Script name | Description


+ 2
- 2
docs/development/setting-up.md Ver fichero

@@ -1,6 +1,6 @@
# Setting up a dev environment

Swagger-UI includes a development server that provides hot module reloading and unminified stack traces, for easier development.
Swagger UI includes a development server that provides hot module reloading and unminified stack traces, for easier development.

### Prerequisites

@@ -20,5 +20,5 @@ Swagger-UI includes a development server that provides hot module reloading and

## Bonus points

- Swagger-UI includes an ESLint rule definition. If you use a graphical editor, consider installing an ESLint plugin, which will point out syntax and style errors for you as you code.
- Swagger UI includes an ESLint rule definition. If you use a graphical editor, consider installing an ESLint plugin, which will point out syntax and style errors for you as you code.
- The linter runs as part of the PR test sequence, so don't think you can get away with not paying attention to it!

+ 18
- 18
docs/usage/configuration.md Ver fichero

@@ -2,11 +2,11 @@

### How to configure

Swagger-UI accepts configuration parameters in four locations.
Swagger UI accepts configuration parameters in four locations.

From lowest to highest precedence:
- The `swagger-config.yaml` in the project root directory, if it exists, is baked into the application
- configuration object passed as an argument to Swagger-UI (`SwaggerUI({ ... })`)
- configuration object passed as an argument to Swagger UI (`SwaggerUI({ ... })`)
- configuration document fetched from a specified `configUrl`
- configuration items passed as key/value pairs in the URL query string

@@ -25,12 +25,12 @@ Type notations are formatted like so:
Parameter name | Docker variable | Description
--- | --- | -----
<a name="configUrl"></a>`configUrl` | `CONFIG_URL` | `String`. URL to fetch external configuration document from.
<a name="dom_id"></a>`dom_id` | `DOM_ID` |`String`, **REQUIRED** if `domNode` is not provided. The id of a dom element inside which SwaggerUi will put the user interface for swagger.
<a name="domNode"></a>`domNode` | _Unavailable_ | `Element`, **REQUIRED** if `dom_id` is not provided. The HTML DOM element inside which SwaggerUi will put the user interface for swagger. Overrides `dom_id`.
<a name="spec"></a>`spec` | `SPEC` | `Object={}`. A JS object describing the OpenAPI Specification. When used, the `url` parameter will not be parsed. This is useful for testing manually-generated specifications without hosting them.
<a name="url"></a>`url` | `URL` | `String`. The url pointing to API definition (normally `swagger.json` or `swagger.yaml`). Will be ignored if `urls` or `spec` is used.
<a name="dom_id"></a>`dom_id` | `DOM_ID` |`String`, **REQUIRED** if `domNode` is not provided. The ID of a DOM element inside which `SwaggerUI` will put its user interface.
<a name="domNode"></a>`domNode` | _Unavailable_ | `Element`, **REQUIRED** if `dom_id` is not provided. The HTML DOM element inside which `SwaggerUI` will put its user interface. Overrides `dom_id`.
<a name="spec"></a>`spec` | `SPEC` | `Object={}`. A JavaScript object describing the OpenAPI definition. When used, the `url` parameter will not be parsed. This is useful for testing manually-generated definitions without hosting them.
<a name="url"></a>`url` | `URL` | `String`. The URL pointing to API definition (normally `swagger.json` or `swagger.yaml`). Will be ignored if `urls` or `spec` is used.
<a name="urls"></a>`urls` | `URLS` | `Array`. An array of API definition objects (`[{url: "<url1>", name: "<name1>"},{url: "<url2>", name: "<name2>"}]`) used by Topbar plugin. When used and Topbar plugin is enabled, the `url` parameter will not be parsed. Names and URLs must be unique among all items in this array, since they're used as identifiers.
<a name="urls.primaryName"></a>`urls.primaryName` | `URLS_PRIMARY_NAME` | `String`. When using `urls`, you can use this subparameter. If the value matches the name of a spec provided in `urls`, that spec will be displayed when Swagger-UI loads, instead of defaulting to the first spec in `urls`.
<a name="urls.primaryName"></a>`urls.primaryName` | `URLS_PRIMARY_NAME` | `String`. When using `urls`, you can use this subparameter. If the value matches the name of a spec provided in `urls`, that spec will be displayed when Swagger UI loads, instead of defaulting to the first spec in `urls`.

##### Plugin system

@@ -38,9 +38,9 @@ Read more about the plugin system in the [Customization documentation](/docs/cus

Parameter name | Docker variable | Description
--- | --- | -----
<a name="layout"></a>`layout` | _Unavailable_ | `String="BaseLayout"`. The name of a component available via the plugin system to use as the top-level layout for Swagger-UI.
<a name="plugins"></a>`plugins` | _Unavailable_ | `Array=[]`. An array of plugin functions to use in Swagger-UI.
<a name="presets"></a>`presets` | _Unavailable_ | `Array=[SwaggerUI.presets.ApisPreset]`. An array of presets to use in Swagger-UI. Usually, you'll want to include `ApisPreset` if you use this option.
<a name="layout"></a>`layout` | _Unavailable_ | `String="BaseLayout"`. The name of a component available via the plugin system to use as the top-level layout for Swagger UI.
<a name="plugins"></a>`plugins` | _Unavailable_ | `Array=[]`. An array of plugin functions to use in Swagger UI.
<a name="presets"></a>`presets` | _Unavailable_ | `Array=[SwaggerUI.presets.ApisPreset]`. An array of presets to use in Swagger UI. Usually, you'll want to include `ApisPreset` if you use this option.

##### Display

@@ -51,26 +51,26 @@ Parameter name | Docker variable | Description
<a name="defaultModelsExpandDepth"></a>`defaultModelsExpandDepth` | `DEFAULT_MODELS_EXPAND_DEPTH` | `Number=1`. The default expansion depth for models (set to -1 completely hide the models).
<a name="defaultModelExpandDepth"></a>`defaultModelExpandDepth` | `DEFAULT_MODEL_EXPAND_DEPTH` | `Number=1`. The default expansion depth for the model on the model-example section.
<a name="defaultModelRendering"></a>`defaultModelRendering` | `DEFAULT_MODEL_RENDERING` | `String=["example"*, "model"]`. Controls how the model is shown when the API is first rendered. (The user can always switch the rendering for a given model by clicking the 'Model' and 'Example Value' links.)
<a name="displayRequestDuration"></a>`displayRequestDuration` | `DISPLAY_REQUEST_DURATION` | `Boolean=false`. Controls the display of the request duration (in milliseconds) for Try-It-Out requests.
<a name="displayRequestDuration"></a>`displayRequestDuration` | `DISPLAY_REQUEST_DURATION` | `Boolean=false`. Controls the display of the request duration (in milliseconds) for "Try it out" requests.
<a name="docExpansion"></a>`docExpansion` | `DOC_EXPANSION` | `String=["list"*, "full", "none"]`. Controls the default expansion setting for the operations and tags. It can be 'list' (expands only the tags), 'full' (expands the tags and operations) or 'none' (expands nothing).
<a name="filter"></a>`filter` | `FILTER` | `Boolean=false OR String`. If set, enables filtering. The top bar will show an edit box that you can use to filter the tagged operations that are shown. Can be Boolean to enable or disable, or a string, in which case filtering will be enabled using that string as the filter expression. Filtering is case sensitive matching the filter expression anywhere inside the tag.
<a name="maxDisplayedTags"></a>`maxDisplayedTags` | `MAX_DISPLAYED_TAGS` | `Number`. If set, limits the number of tagged operations displayed to at most this many. The default is to show all operations.
<a name="operationsSorter"></a>`operationsSorter` | _Unavailable_ | `Function=(a => a)`. Apply a sort to the operation list of each API. It can be 'alpha' (sort by paths alphanumerically), 'method' (sort by HTTP method) or a function (see Array.prototype.sort() to know how sort function works). Default is the order returned by the server unchanged.
<a name="showExtensions"></a>`showExtensions` | `SHOW_EXTENSIONS` | `Boolean=false`. Controls the display of vendor extension (`x-`) fields and values for Operations, Parameters, and Schema.
<a name="showCommonExtensions"></a>`showCommonExtensions` | `SHOW_COMMON_EXTENSIONS` | `Boolean=false`. Controls the display of extensions (`pattern`, `maxLength`, `minLength`, `maximum`, `minimum`) fields and values for Parameters.
<a name="tagSorter"></a>`tagsSorter` | _Unavailable_ | `Function=(a => a)`. Apply a sort to the tag list of each API. It can be 'alpha' (sort by paths alphanumerically) or a function (see [Array.prototype.sort()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort) to learn how to write a sort function). Two tag name strings are passed to the sorter for each pass. Default is the order determined by Swagger-UI.
<a name="onComplete"></a>`onComplete` | _Unavailable_ | `Function=NOOP`. Provides a mechanism to be notified when Swagger-UI has finished rendering a newly provided definition.
<a name="tagSorter"></a>`tagsSorter` | _Unavailable_ | `Function=(a => a)`. Apply a sort to the tag list of each API. It can be 'alpha' (sort by paths alphanumerically) or a function (see [Array.prototype.sort()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/sort) to learn how to write a sort function). Two tag name strings are passed to the sorter for each pass. Default is the order determined by Swagger UI.
<a name="onComplete"></a>`onComplete` | _Unavailable_ | `Function=NOOP`. Provides a mechanism to be notified when Swagger UI has finished rendering a newly provided definition.

##### Network

Parameter name | Docker variable | Description
--- | --- | -----
<a name="oauth2RedirectUrl"></a>`oauth2RedirectUrl` | _Unavailable_ | `String`. OAuth redirect URL.
<a name="requestInterceptor"></a>`requestInterceptor` | _Unavailable_ | `Function=(a => a)`. MUST be a function. Function to intercept remote definition, Try-It-Out, and OAuth2 requests. Accepts one argument requestInterceptor(request) and must return the modified request, or a Promise that resolves to the modified request.
<a name="responseInterceptor"></a>`responseInterceptor` | _Unavailable_ | `Function=(a => a)`. MUST be a function. Function to intercept remote definition, Try-It-Out, and OAuth2 responses. Accepts one argument responseInterceptor(response) and must return the modified response, or a Promise that resolves to the modified response.
<a name="requestInterceptor"></a>`requestInterceptor` | _Unavailable_ | `Function=(a => a)`. MUST be a function. Function to intercept remote definition, "Try it out", and OAuth 2.0 requests. Accepts one argument requestInterceptor(request) and must return the modified request, or a Promise that resolves to the modified request.
<a name="responseInterceptor"></a>`responseInterceptor` | _Unavailable_ | `Function=(a => a)`. MUST be a function. Function to intercept remote definition, "Try it out", and OAuth 2.0 responses. Accepts one argument responseInterceptor(response) and must return the modified response, or a Promise that resolves to the modified response.
<a name="showMutatedRequest"></a>`showMutatedRequest` | `SHOW_MUTATED_REQUEST` | `Boolean=true`. If set to `true`, uses the mutated request returned from a requestInterceptor to produce the curl command in the UI, otherwise the request before the requestInterceptor was applied is used.
<a name="supportedSubmitMethods"></a>`supportedSubmitMethods` | `SUPPORTED_SUBMIT_METHODS` | `Array=["get", "put", "post", "delete", "options", "head", "patch", "trace"]`. List of HTTP methods that have the Try it out feature enabled. An empty array disables Try it out for all operations. This does not filter the operations from the display.
<a name="validatorUrl"></a>`validatorUrl` | `VALIDATOR_URL` | `String="https://online.swagger.io/validator" OR null`. By default, Swagger-UI attempts to validate specs against swagger.io's online validator. You can use this parameter to set a different validator URL, for example for locally deployed validators ([Validator Badge](https://github.com/swagger-api/validator-badge)). Setting it to `null` will disable validation.
<a name="supportedSubmitMethods"></a>`supportedSubmitMethods` | `SUPPORTED_SUBMIT_METHODS` | `Array=["get", "put", "post", "delete", "options", "head", "patch", "trace"]`. List of HTTP methods that have the "Try it out" feature enabled. An empty array disables "Try it out" for all operations. This does not filter the operations from the display.
<a name="validatorUrl"></a>`validatorUrl` | `VALIDATOR_URL` | `String="https://online.swagger.io/validator" OR null`. By default, Swagger UI attempts to validate specs against swagger.io's online validator. You can use this parameter to set a different validator URL, for example for locally deployed validators ([Validator Badge](https://github.com/swagger-api/validator-badge)). Setting it to `null` will disable validation.
<a name="withCredentials"></a>`withCredentials` | `WITH_CREDENTIALS` | `Boolean=false` If set to `true`, enables passing credentials, [as defined in the Fetch standard](https://fetch.spec.whatwg.org/#credentials), in CORS requests that are sent by the browser. Note that Swagger UI cannot currently set cookies cross-domain (see [swagger-js#1163](https://github.com/swagger-api/swagger-js/issues/1163)) - as a result, you will have to rely on browser-supplied cookies (which this setting enables sending) that Swagger UI cannot control.

##### Macros
@@ -86,7 +86,7 @@ Parameter name | Docker variable | Description

Method name | Docker variable | Description
--- | --- | -----
<a name="initOAuth"></a>`initOAuth` | [_See `oauth2.md`_](./oauth2.md) | `(configObj) => void`. Provide Swagger-UI with information about your OAuth server - see the OAuth2 documentation for more information.
<a name="initOAuth"></a>`initOAuth` | [_See `oauth2.md`_](./oauth2.md) | `(configObj) => void`. Provide Swagger UI with information about your OAuth server - see the [OAuth 2.0 documentation](./oauth2.md) for more information.
<a name="preauthorizeBasic"></a>`preauthorizeBasic` | _Unavailable_ | `(authDefinitionKey, username, password) => action`. Programmatically set values for a Basic authorization scheme.
<a name="preauthorizeApiKey"></a>`preauthorizeApiKey` | _Unavailable_ | `(authDefinitionKey, apiKeyValue) => action`. Programmatically set values for an API key authorization scheme.



+ 6
- 6
docs/usage/cors.md Ver fichero

@@ -6,7 +6,7 @@ You can read about CORS here: http://www.w3.org/TR/cors.

There are two cases where no action is needed for CORS support:

1. swagger-ui is hosted on the same server as the application itself (same host *and* port).
1. Swagger UI is hosted on the same server as the application itself (same host *and* port).
2. The application is located behind a proxy that enables the required CORS headers. This may already be covered within your organization.

Otherwise, CORS support needs to be enabled for:
@@ -33,15 +33,15 @@ Content-Length: 0

This tells us that the petstore resource listing supports OPTIONS, and the following headers: `Content-Type`, `api_key`, `Authorization`.

- Try swagger-ui from your file system and look at the debug console. If CORS is not enabled, you'll see something like this:
- Try Swagger UI from your file system and look at the debug console. If CORS is not enabled, you'll see something like this:

```
XMLHttpRequest cannot load http://sad.server.com/v2/api-docs. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
```

Swagger-UI cannot easily show this error state.
Swagger UI cannot easily show this error state.

- Using the http://www.test-cors.org website. Keep in mind this will show a successful result even if `Access-Control-Allow-Headers` is not available, which is still required for Swagger-UI to function properly.
- Using the http://www.test-cors.org website. Keep in mind this will show a successful result even if `Access-Control-Allow-Headers` is not available, which is still required for Swagger UI to function properly.

### Enabling CORS

@@ -51,10 +51,10 @@ Other servers/frameworks may provide you information on how to enable it specifi

### CORS and Header Parameters

Swagger lets you easily send headers as parameters to requests. The name of these headers *MUST* be supported in your CORS configuration as well. From our example above:
Swagger UI lets you easily send headers as parameters to requests. The name of these headers *MUST* be supported in your CORS configuration as well. From our example above:

```
Access-Control-Allow-Headers: Content-Type, api_key, Authorization
```

Only headers with these names will be allowed to be sent by Swagger-UI.
Only headers with these names will be allowed to be sent by Swagger UI.

+ 7
- 7
docs/usage/deep-linking.md Ver fichero

@@ -1,13 +1,13 @@
# `deepLinking` parameter

Swagger-UI allows you to deeply link into tags and operations within a spec. When Swagger-UI is provided a URL fragment at runtime, it will automatically expand and scroll to a specified tag or operation.
Swagger UI allows you to deeply link into tags and operations within a spec. When Swagger UI is provided a URL fragment at runtime, it will automatically expand and scroll to a specified tag or operation.

## Usage

👉🏼 Add `deepLinking: true` to your Swagger-UI configuration to enable this functionality. This is demonstrated in [`dist/index.html`](https://github.com/swagger-api/swagger-ui/blob/master/dist/index.html).
👉🏼 Add `deepLinking: true` to your Swagger UI configuration to enable this functionality. This is demonstrated in [`dist/index.html`](https://github.com/swagger-api/swagger-ui/blob/master/dist/index.html).

When you expand a tag or operation, Swagger-UI will automatically update its URL fragment with a deep link to the item.
Conversely, when you collapse a tag or operation, Swagger-UI will clear the URL fragment.
When you expand a tag or operation, Swagger UI will automatically update its URL fragment with a deep link to the item.
Conversely, when you collapse a tag or operation, Swagger UI will clear the URL fragment.

You can also right-click a tag name or operation path in order to copy a link to that tag or operation.

@@ -19,13 +19,13 @@ The fragment is formatted in one of two ways:
- `#/{tagName}/{operationId}`, to trigger the focus of a specific operation within a tag

`operationId` is the explicit operationId provided in the spec, if one exists.
Otherwise, Swagger-UI generates an implicit operationId by combining the operation's path and method, and escaping non-alphanumeric characters.
Otherwise, Swagger UI generates an implicit operationId by combining the operation's path and method, and escaping non-alphanumeric characters.

## FAQ

> I'm using Swagger-UI in an application that needs control of the URL fragment. How do I disable deep-linking?
> I'm using Swagger UI in an application that needs control of the URL fragment. How do I disable deep-linking?

This functionality is disabled by default, but you can pass `deepLinking: false` into Swagger-UI as a configuration item to be sure.
This functionality is disabled by default, but you can pass `deepLinking: false` into Swagger UI as a configuration item to be sure.

> Can I link to multiple tags or operations?



+ 4
- 4
docs/usage/installation.md Ver fichero

@@ -6,7 +6,7 @@

We publish two modules to npm: **`swagger-ui`** and **`swagger-ui-dist`**.

**`swagger-ui`** is meant for consumption by JavaScript web projects that include module bundlers, such as Webpack, Browserify, and Rollup. Its main file exports Swagger-UI's main function, and the module also includes a namespaced stylesheet at `swagger-ui/dist/swagger-ui.css`. Here's an example:
**`swagger-ui`** is meant for consumption by JavaScript web projects that include module bundlers, such as Webpack, Browserify, and Rollup. Its main file exports Swagger UI's main function, and the module also includes a namespaced stylesheet at `swagger-ui/dist/swagger-ui.css`. Here's an example:

```javascript
import SwaggerUI from 'swagger-ui'
@@ -23,7 +23,7 @@ In contrast, **`swagger-ui-dist`** is meant for server-side projects that need a
_Note: we suggest using `swagger-ui` when your tooling makes it possible, as `swagger-ui-dist`
will result in more code going across the wire._

The module's contents mirrors the `dist` folder you see in the Git repository. The most useful file is `swagger-ui-bundle.js`, which is a build of Swagger-UI that includes all the code it needs to run in one file. The folder also has an `index.html` asset, to make it easy to serve Swagger-UI like so:
The module's contents mirrors the `dist` folder you see in the Git repository. The most useful file is `swagger-ui-bundle.js`, which is a build of Swagger UI that includes all the code it needs to run in one file. The folder also has an `index.html` asset, to make it easy to serve Swagger UI like so:

```javascript
const express = require('express')
@@ -65,7 +65,7 @@ docker pull swaggerapi/swagger-ui
docker run -p 80:8080 swaggerapi/swagger-ui
```

Will start nginx with swagger-ui on port 80.
Will start nginx with Swagger UI on port 80.

Or you can provide your own swagger.json on your host

@@ -85,7 +85,7 @@ For more information on controlling Swagger UI through the Docker image, see the

### unpkg

You can embed Swagger-UI's code directly in your HTML by using unpkg's interface:
You can embed Swagger UI's code directly in your HTML by using unpkg's interface:

```html
<script src="//unpkg.com/swagger-ui-dist@3/swagger-ui-bundle.js"></script>


+ 1
- 1
docs/usage/limitations.md Ver fichero

@@ -33,6 +33,6 @@ Forbidden headers include:
> _[Forbidden header names (developer.mozilla.org)](https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name)_

The biggest impact of this is that OpenAPI 3.0 Cookie parameters cannot be
controlled when running Swagger-UI in a browser.
controlled when running Swagger UI in a browser.

For more context, see [#3956](https://github.com/swagger-api/swagger-ui/issues/3956).

+ 2
- 2
docs/usage/oauth2.md Ver fichero

@@ -1,5 +1,5 @@
# OAuth2 configuration
You can configure OAuth2 authorization by calling the `initOAuth` method.
# OAuth 2.0 configuration
You can configure OAuth 2.0 authorization by calling the `initOAuth` method.

Property name | Docker variable | Description
--- | --- | ------


+ 10
- 10
docs/usage/version-detection.md Ver fichero

@@ -1,17 +1,17 @@
# Detecting your Swagger-UI version
# Detecting your Swagger UI version

At times, you're going to need to know which version of Swagger-UI you use.
At times, you're going to need to know which version of Swagger UI you use.

The first step would be to detect which major version you currently use, as the method of detecting the version has changed. If your Swagger-UI has been heavily modified and you cannot detect from the look and feel which major version you use, you'd have to try both methods to get the exact version.
The first step would be to detect which major version you currently use, as the method of detecting the version has changed. If your Swagger UI has been heavily modified and you cannot detect from the look and feel which major version you use, you'd have to try both methods to get the exact version.

To help you visually detect which version you're using, we've included supporting images.


# Swagger-UI 3.X
# Swagger UI 3.x

![Swagger-UI 3](/docs/images/swagger-ui3.png)
![Swagger UI 3](/docs/images/swagger-ui3.png)

Some distinct identifiers to Swagger-UI 3.X:
Some distinct identifiers to Swagger UI 3.x:
- The API version appears as a badge next to its title.
- If there are schemes or authorizations, they'd appear in a bar above the operations.
- Try it out functionality is not enabled by default.
@@ -27,11 +27,11 @@ If you've determined this is the version you have, to find the exact version:
Note: This functionality was added in 3.0.8. If you're unable to execute it, you're likely to use an older version, and in that case the first step would be to upgrade.


# Swagger-UI 2.X and under
# Swagger UI 2.x and under

![Swagger-UI 2](/docs/images/swagger-ui2.png)
![Swagger UI 2](/docs/images/swagger-ui2.png)

Some distinct identifiers to Swagger-UI 3.X:
Some distinct identifiers to Swagger UI 3.x:
- The API version appears at the bottom of the page.
- Schemes are not rendered.
- Authorization, if rendered, will appear next to the navigation bar.
@@ -42,7 +42,7 @@ Some distinct identifiers to Swagger-UI 3.X:
If you've determined this is the version you have, to find the exact version:
- Navigate to the sources of the UI. Either on your disk or via the view page source functionality in your browser.
- Find an open the `swagger-ui.js`
- At the top of the page, there would be a comment containing the exact version of swagger-ui. This example shows version `2.2.9`:
- At the top of the page, there would be a comment containing the exact version of Swagger UI. This example shows version `2.2.9`:

```
/**


Cargando…
Cancelar
Guardar