Access control to Hub


(Stonelonely) #1

We want to refer to stoplight.io site for document sharing, but we want to make it available to signed-up users only. We tried reverse proxy approach similar to what described at https://docs.stoplight.io/documentation/embed-your-hub. We were able to proxy the web request, but we cannot figure out how to embed stoplight.io web page inside our React app.

Username and password Login is good for internal doc sharing but hurts the user experience for external users.

Is the OAuth support only for API? It seems to be the right approach that the user can switch smoothly between our own website and Stoplight documentation site.

What other options can we have?

btw, the urls in your doc from the above link seems missing the .io suffix, e.g. ingress.docs.stoplight/your-base-path should be ingress.docs.stoplight.io/your-base-path


(Taylor Barnett) #2

Have you considered self-hosting it within your React app?

Like what this section talks about:

You are correct about OAuth.

Another option you have is if you could use our SAML support.


(Stonelonely) #3

Thanks for the information. We are aware of this option of self-hosting. Looks like it’s going to work. We are not sure how much work need to be done to make it as part of our dev cycle though. It seems pretty manual and isolated, e.g. download the static assets. If there are programmable API interface so we can embed the step either during dev or CI, that would be great. Is there any example that some of your user did this successfully in a more programmatic way?


(Taylor Barnett) #4

You can do some of the steps programmatically, like rebuild and download static zip file: https://docs.stoplight.io/api-reference/documentation/download/getdocsbuildsdownload

I know of a few users who use the static files, but it is for very specific reasons. Although some have moved back to just hosting via Stoplight because they decided it was okay to publicly host the docs. I don’t really have any to show though since they have their docs hidden away.

I know everyone’s use case is different, but sometimes you can make progress on thinking deeper about why you want to hide away the API. It isn’t like you are giving access to it actually working, so sometimes teams change their minds. Just a thought.