feat: Add PathPrefix to webui

[maxlerebourg]

This PR add the a WEBUI_PATH_PREFIX option to help users to define more precisely where the WebUI is available.
Fix #1833

[versity-github]

This won't automatically run in continuous integration without approval. A member of the Versity organization must allow it.

[benmcclelland]

Instead of changing the embed logic, we can just modify the PathPrefix to match the webui-path-prefix in the filesystem middleware instead. I also was expecting this to be hosted on the s3 port when webui-path-prefix defined so that we could disable the CORS settings?

[benmcclelland]

Instead of changing the embed logic, we can just modify the PathPrefix to match the webui-path-prefix in the filesystem middleware instead. I also was expecting this to be hosted on the s3 port when webui-path-prefix defined so that we could disable the CORS settings?

I can help with these changes if you need me to take a swing at this.

[maxlerebourg]

Instead of changing the embed logic, we can just modify the PathPrefix to match the webui-path-prefix in the filesystem middleware instead. I also was expecting this to be hosted on the s3 port when webui-path-prefix defined so that we could disable the CORS settings?

I'm not sure which middleware you're referring to. If you're talking about this configuration:

filesystem.Config{
  Root:         http.FS(processedFS),
  PathPrefix:   "web",  // This one
}

The PathPrefix here refers to the root directory within the embedded FS (webFS or processedFS), not the WebUI path prefix that I defined with the new option.

I wanted to minimize changes to the existing codebase, so I kept the current behavior with two separate servers (IP:Port).

I can help with these changes if you need me to take a swing at this.

Feel free to take over the PR if you'd like to merge the two servers.

[soakes]

any ideas when this is going to be merged?

[benmcclelland]

any ideas when this is going to be merged?

This is not going to be merged in the current form. I am looking into what it would take to refactor this PR, but the /api/gateways call the client makes is making this problematic. It would have to take over multiple routes in the current form. This might be pushed back to better design investigation.

[soakes]

any ideas when this is going to be merged?

This is not going to be merged in the current form. I am looking into what it would take to refactor this PR, but the /api/gateways call the client makes is making this problematic. It would have to take over multiple routes in the current form. This might be pushed back to better design investigation.

Thanks for the update, will keep an eye on here. Must admit I didnt look over the code, only saw the feature which I needed.

[benmcclelland]

any ideas when this is going to be merged?

This is not going to be merged in the current form. I am looking into what it would take to refactor this PR, but the /api/gateways call the client makes is making this problematic. It would have to take over multiple routes in the current form. This might be pushed back to better design investigation.

Thanks for the update, will keep an eye on here. Must admit I didnt look over the code, only saw the feature which I needed.

The original idea was to try to host the webui on the same port as s3 service masking a bucket with the specified webui route. This would prevent the need for all of the CORS headaches. But now this is pivoting to just being able to specify the route prefix for the webui on the separate port. Which I guess would allow for a reverse proxy to route these to different ports if needed. Is this the feature you are needing? I'm curious the specific use case here to make sure the design decisions account for all desired cases.

[soakes]

any ideas when this is going to be merged?

This is not going to be merged in the current form. I am looking into what it would take to refactor this PR, but the /api/gateways call the client makes is making this problematic. It would have to take over multiple routes in the current form. This might be pushed back to better design investigation.

Thanks for the update, will keep an eye on here. Must admit I didnt look over the code, only saw the feature which I needed.

The original idea was to try to host the webui on the same port as s3 service masking a bucket with the specified webui route. This would prevent the need for all of the CORS headaches. But now this is pivoting to just being able to specify the route prefix for the webui on the separate port. Which I guess would allow for a reverse proxy to route these to different ports if needed. Is this the feature you are needing? I'm curious the specific use case here to make sure the design decisions account for all desired cases.

So the use case is like this, https://s3.exmaple.com being your main s3 endpoint for your cli/automation clients but for management URL would be https://s3.example.com/versity for example. This is also how ive been doing it with like rustfs for a while now. This allows just a single domain or subdomain for hosting but still have two different endpoints connected.

[maxlerebourg]

I tested an interesting approach: I uploaded the entire WebUI to a bucket named gui and set a public policy for GetObject operations as shown below. After that, everything works exactly as expected when accessing the /gui endpoint.
The only exception is calls to /api/gateways (which fail silently).
And I need to access to /gui/index.html at first.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FullS3Access",
      "Effect": "Allow",
      "Principal": [
        "*"
      ],
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::gui",
        "arn:aws:s3:::gui/*"
      ]
    }
  ]
}

[jacksgt]

Regardless of the proposed implementation, I'd definitely like to see the feature that you can server S3 API, Web UI and ideally also Admin API from the same domain. In my experience, this makes it significantly easier to deploy and maintain applications from an administrator point of view (ingress, firewall rules, certificates etc.).