Prefilled Auth token for "Try It" feature

[bzmw]

User story.

As an owner of API documentation, I can pass in an Authorization Token in React, so that Customers of my API Documentation can use the "TryIt" functionality without having to search for an API key of their own.

Describe the solution you'd like

On instantiation of the StoplightProject component I would like to pass in a value. Ex:

<StoplightProject
  sampleAuth="my-sample-auth-token"
  ...
</StoplightProject>

Comments

This is definitely something that I need for my API Reference, our clients are external to my company and definitely do not want to go digging for an API Token. If this isn't going to prioritized I think I'll end up hacking it in through some React magic for my specific use case.

[philsturgeon]

This is a great idea, but it will be tricky to plan out.

There can be many different types of auth, maybe multiple used at the same time. Give this OAS:

components:
  securitySchemes:
    BasicAuth:
      type: http
      scheme: basic
    BearerAuth:
      type: http
      scheme: bearer
    ApiKeyAuth:
      type: apiKey
      in: header
      name: X-API-Key

What would the HTML look like for it?

I dont know if we can do dynamic attribute names:

<elements-stoplight-project
  ApiKeyAuthValue="my-sample-auth-token"
  ...
</elements-stoplight-project>

Maybe we could try some sort of special syntax:

<elements-stoplight-project
  parameters="ApiKeyAuth:my-sample-auth-token"
  ...
</elements-stoplight-project>

Or... something like that. That would predefine values for any parameters then, but it looks a bit odd, and might have a rough time with multiple values.

The JS interface is easier, we'd just pass an object:

<StoplightProject
  parameters={{ ApiKeyAuth: "my-sample-auth-token" }}
  ...
</StoplightProject>

Anyway, curious what you think about this.

@marcelltoth any ideas on your end?

[bzmw]

Personally I prefer the special syntax in your second example because it matches closest to the JS interface.

---

It's not super awesome but could we throw in some custom fields into the OAS to support something like this?

components:
  securitySchemes:
    BasicAuth:
      type: http
      scheme: basic
      x-sample-token: my-sample-auth-token
...

[marekhrabe]

I was trying to achieve this and it seems like the app is already loading the security values from the localStorage.

Calling localStorage.TryIt_securitySchemeValues = JSON.stringify({'Token': 'test123'}) before the documentation is initialized prefills the secret exactly as intended. A nicer API way would be useful but I though to share this workaround for others driving by. The shape of that object would be dependant on how you've named your security schemes.

Knowing there is already some object that describes the security scheme values, maybe this JSON/object would also be the ideal format for exposing the functionality in the component prop or html attribute.

[danielsharvey]

@marekhrabe Thanks, this works well. Although, something to handle token refresh would be good - I will go looking to achieve this later :)

FYI for others reading, the Token in the example above is the name of the security scheme from the Swagger:

{
  // ...
  "components": {
    "securitySchemes": {
      "<scheme-name>": {
        // ...
    }
  }
}

I was trying to achieve this and it seems like the app is already loading the security values from the localStorage.

Calling localStorage.TryIt_securitySchemeValues = JSON.stringify({'Token': 'test123'}) before the documentation is initialized prefills the secret exactly as intended. A nicer API way would be useful but I though to share this workaround for others driving by. The shape of that object would be dependant on how you've named your security schemes.

Knowing there is already some object that describes the security scheme values, maybe this JSON/object would also be the ideal format for exposing the functionality in the component prop or html attribute.

[chohmann]

Hello!

Our team recently took over the stewardship of the elements repo.

Due the volume of un-triaged issues that are pretty old and the time it would take us to get caught up on all of them, we kindly ask that you open up a new ticket if this is still an issue you're struggling with.

If you open a new issue please include:

• clear steps to reproduce that include example OAS specs, application setup, code, etc.
• the error or issue you are experiencing
• the expected behavior

We will be triaging any new tickets in a timely manner.

Thank you for understanding!