Duplicate: multiple auth section slots

[splitbrain]

Currently only the whole auth page can be replaced using the authentication slot. It would be great to have a slot to add content without losing the ability to add an API key.

[wparad]

Closing as this is a duplicate of #193. In that issue it explains how to do this, alternatives, and why this doesn't exist as a separate slot. If for some reason that doesn't work out, please do let us know.

[splitbrain]

Hmm, I'm not sure I understand that other issue.

there are already API methods to render those same auth components via custom HTML

I interpret this as such, that I could add a call to an existing web component to my custom HTML to have the API key Input fields where ever I want them in my own HTML. That would be indeed the perfect solution, but I don't see what those components would be called. They're not in here: https://github.com/Authress-Engineering/openapi-explorer/tree/release/2.1/src/components are they?

Maybe you could add an example somewhere in the docs?

PS: I am using your web component as via the unpkg cdn, I'm not extending anything and would prefer not to have to write any JavaScript.

[wparad]

Right now it is one line of javascript and the associated HTML that would need to be added. As the Auth page is vanilla, it hasn't made sense to attempt to add additional slots there. The example javascript snippet in #193, and should work out of the box. If you find a problem with that, it is something we would definitely want to improve.

The doc example for this is lean, but it is here: https://github.com/Authress-Engineering/openapi-explorer/blob/release/2.1/docs/documentation.md#library-api

I'll copy it here for brevity:

document.getElementsByTagName("openapi-explorer")[0].setAuthenticationConfiguration('basicAuth', { token: 'user:password' });

It may feel like overengineering, but after much brainstorming, it just hasn't been clear where slots would go and what they would look like. Rather than introducing something that doesn't benefit anyone (because we did it wrong) the mentality has been, wait until there is a problem. In this case the solution is "simple javascript". If that doesn't work for some reason, we would love to know more about your scenario where javascript can't be used.

[splitbrain]

The doc you link says:

Set a token for methods that require security for a particular security scheme id.

But that's not what I want. I want to keep the ability for the user to provide their own credentials. I just want to add some explanations below:

From your answer I get that I could maybe use JavaScript to insert some HTML into the DOM generated by your component (though I would have expected that to be prevented by the component's shadow dom). However even if that is possible, it's not a route I want to go. It would be more code that needs to be maintained and I rather focus on maintaining my own project.

If adding a slot there is difficult or not in the scope of your project that's fine with me. I can also add my few words to the overview page. The authentication page would just have been a better fit.

Thanks for the super prompt responses btw!

[wparad]

Nah, I'm definitely not suggesting to dynamically insert html into the DOM.

What I am suggesting replace the Auth slot with your content. You can add exactly what you want. For the buttons/input text fields, you only need call the javascript line of code when your custom SET button is pressed.

for example, I just copied out the DOM for our public tester:

<div slot="authentication">
      <div class="section-padding">
         <div class="sub-title regular-font">AUTHENTICATION</div>
         <table role="presentation" class="m-table" style="width:100%">
            <tr>
               <td colspan="1" style="max-width:500px;overflow-wrap:break-word">
                  <div style="min-height:24px"> <span style="font-weight:700">User Credentials</span>  </div>
               </td>
               <td
                  colspan="3">
                  Send <code>Authorization</code> in <code>header</code> containing the word <code>Bearer</code> followed by a space
                  and then the JWT. 
                  <form style="display:flex"> 
                    <input id="username" type="text" spellcheck="false" class="api-key-input fs-exclude" data-hj-suppress data-sl="mask" value placeholder="username">
                    <input id="password" type="password" spellcheck="false" class="api-key-input fs-exclude" data-hj-suppress data-sl="mask" value placeholder="password">
                    <button type="submit" class="m-btn thin-border" style="margin-left:5px" part="btn btn-outline">SET</button> 
                  </form>
               </td>
            </tr>
         </table>
      </div>
</section>

Then you can hook up the button click to the javascript to grab the properties from your input form and pass those to the function: (or something like this

const username = document.getByElementId('username').value;
const password = document.getByElementId('password').value;
document.getElementsByTagName("openapi-explorer")[0].setAuthenticationConfiguration('basicAuth', { token: `${username}:${password}' });

[splitbrain]

Ah I see. TBH that seems even worse, as I am duplicating something you already did. And I won't be benefiting from any improvement you might make to those forms in the future.

It will also not dynamically update from the openapi spec. So if a different auth mechanism is added to the API this custom code needs to be updated.

[wparad]

There's really no reason to be concerned, in the unlikely event we ever added more content to the auth screen it would lend itself to better telling us where slots could go, and it would be easy to convert to the standard and discard the custom logic.

But since this is such a huge concern for you, we'll throw in an authentication-footer slot.

See release 2.1.641. Cheers.