Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor setting of - Server.OpenApiSpec.Servers #248

Closed
dylanhitt opened this issue Dec 4, 2024 · 8 comments · Fixed by #273
Closed

refactor setting of - Server.OpenApiSpec.Servers #248

dylanhitt opened this issue Dec 4, 2024 · 8 comments · Fixed by #273
Assignees
Labels

Comments

@dylanhitt
Copy link
Collaborator

Right now we do it in the constructor of Server function. We should push this closer to startup of the server as we can interpret if the user is running an http or https server as well as get the proper address since #245 we do not know the final address we use until s.setup() is called nor if the server is https or http.

In regards to just printing. We can just assume http for now. If we find we have a reason to allow the user to ensure the server setup is https we can update the s.OutputOpenAPISpec() to be s.OutputOpenAPISpec(isTLS bool). We really don't have another way of doing this since we truly don't know if the server is an http or https webserver until startup.

@dylanhitt dylanhitt self-assigned this Dec 4, 2024
@DimShadoWWW
Copy link

Another use case to consider is when the service is accessed through a reverse proxy, requiring the ability to specify a public address instead of relying on the default configuration.

@dylanhitt
Copy link
Collaborator Author

I believe that's already possible with WithAddr as well as WithListener in the future. Unless I'm not understanding what you mean exactly. Could you elaborate?

@EwenQuim
Copy link
Member

EwenQuim commented Dec 6, 2024

Another use case to consider is when the service is accessed through a reverse proxy, requiring the ability to specify a public address instead of relying on the default configuration.

Mmh I don't see any issue, I mean I deploy Fuego on my infra with a reverse proxy without issue.
Also, we expose s.Server, the net/http.Server, so I personnaly am not stuck.

Please tell us more, I'll be happy to help!

@DimShadoWWW
Copy link

Apologies for the delay.

The issue I encountered is that when deploying multiple instances of the service (e.g., Docker containers) behind a reverse proxy with different hostnames, the URL to swagger/openapi.json includes the "internal" address of the service rather than the public address of the reverse proxy, making it inaccessible.

The solution I implemented was to redefine DefaultOpenAPIHandler to specify the public address explicitly. Additionally, I configured the public address using the following code:

s.OpenApiSpec.Servers = []*openapi3.Server{
		{
			URL:         viper.GetString("public-address"),
			Description: "test server",
		},
	}

@dylanhitt
Copy link
Collaborator Author

Oh I see. The URL for the input here needs to be configurable.

@EwenQuim
Copy link
Member

EwenQuim commented Dec 9, 2024

Yes I'm doing this too, instead of auto-discovering its own public address, I just configure the public URL manually.

But I guess that's fine doing like you did, I also do that too for all the things that are purely OpenAPI-related, without too much impact on the running server.

@DimShadoWWW
Copy link

Yes, it is better to configure the public URL manually rather than adding complexity by attempting to auto-discover it. This approach also allows reusing the public address consistently wherever it is needed.

@dylanhitt
Copy link
Collaborator Author

Will be best to wait for the finish of #262

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants