Feature request: Append content to auth page

[addshore]

There is a slot to replace the whole auth page

<div slot="authentication">
  <h1>Authentication</h1>
  <div>Replaces the authentication section</div>
</div>

However if I want to make use of the default auth token input, I'd love to just be able to add content below and or above the default page

[wparad]

Could be interesting, but the screen is incredibly simple, and there are already API methods to render those same auth components via custom HTML and inject credentials. What are you thinking about for content there. If there is something useful there we could just directly add it into the library. What sort of content would you like on this tab?

[addshore]

Thanks for the speedy reply!

I'd generally like to describe the behavior's of the token that is used for authentication, and probably also link to / explain how to generate the token.

Out of the box it looks a little bare, and as the menu item is called "authentication" I'd expect this is where people will end up clicking to try to learn how to authenticate

[wparad]

How complex is your authentication? For instance at Authress, we replaced the Authentication with this: https://authress.io/app/#/api?route=auth

Then we used the events to automatically inject in the necessary token.

You can also dynamically set the token using the authentication library api So you can make this whole part look exactly like you want and still have the hooks to the functionality.

I don't know what your authentication flow looks like or which one you are using, but if it is really just the API key one, then using the function setAuthenticationConfiguration() with a custom UI component might be the best for your use case.

If that doesn't work then we can try to figure out if there is a slot that makes sense to inject here.

As an aside, I do want to caution that pushing the API keys into the UI is a bit unsafe. And depending on how you are generating the API keys they could be even more potential issues with that. I don't know if you are interesting in some relevant docs about that, but security of apis is my specialty. FWIW, Bearer JWTs is going to likely be a much safer option for your users/service clients.

[addshore]

https://authress.io/app/#/api?route=auth looks like exactly what I want to aim for. I guess I was just trying to avoid having to reimplement the input box and having it tie into the rendered sample requests and of course the actual requests getting fired off. So I'll go ahead and give setAuthenticationConfiguration a go with a custom page.

Any docs you think may be of interest to me I'd love to give a once over :) We will be using bearer JWTs, and if any auto generated tokens are used in the UI I expect I'll end up creating them with a rather short TTL lifespan

[wparad]

FWIW, if you inject the token using either function--i.e. the curl request OR the setAuthenticationConfiguration--then the full curl will contain the relevant information. it is dynamically updated.

For instance, this is literally our requestInterceptor

requestInterceptor(event) {
      if (this.apiToken) {
        event.detail.request.options.headers.append('Authorization', this.apiToken);
      }

      if (event.detail.request.explorerLocation === 'get-/' || event.detail.request.explorerLocation === 'post-/api/authentication/oauth/tokens' && event.detail.request.url.match('authress.io')) {
        this.showOauthPopupDetails = true;
        return;
      }
    },

with (this is vue):

<openapi-explorer table collapse v-if="openapiSpecificationUrl" :explorer-location="explorerLocation"
:spec-url="openapiSpecificationUrl" @request="requestInterceptor" @response="responseInterceptor" />

Same goes for the setAuthenticationConfiguration, there's an example in the docs:

https://github.com/Rhosys/openapi-explorer/blob/5595a4617019e27259f7005b290e3ebd37138619/docs/documentation.md?plain=1#L44

and a usage in the mocks: https://github.com/Rhosys/openapi-explorer/blob/5595a4617019e27259f7005b290e3ebd37138619/mocks/index.html#L53

If none of those help, just let us know.

We will be using bearer JWTs, and if any auto generated tokens are used in the UI I expect I'll end up creating them with a rather short TTL lifespan

:+1:, if you run into any problems there, feel free to let us know, since, um, we have a product specifically for that :wink:.

With that, I'll close this ticket for now.