You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@gnugomez that would also be something useful to work on. We should tell the frontend what the maximum supported extension size is, e.g. via the existing /api/version endpoint that the frontend already fetches. If the user wants to upload an extension larger than the allowed max size, already prevent the extension from being uploaded.
Currently, the upload happens no matter how big the extension is, and will then fail if the server reads more than allowed bytes.
@netomi I'm not sure if using a dynamic value coming from the API here might be a good idea, also taking into account that this limit is not something that changes much, wouldn't it be better to consume an static constant that shares the same value as ovsx.publishing.max-content-size?
The only way to consume that statically from the frontend and make it configurable at the same time would be to add a page setting to the React app, so when you initialise the app it takes the value. But you would have to change that in both server and webui config...
Maybe it is something that we may want to retrieve from a settings endpoint then..
Why don't we move the GET /admin/settings out of admin?
I guess we could add a new value to the GET /api/version return, but doesn't that defeat a bit the purpose of the endpoint itself?
/admin/settings is for admin only and this is fine.
we could make a new endpoint /api/config that includes things relevant for the frontend, e.g. version, upload limit, ... and remove the version one though.
Activity
netomi commentedon Jun 30, 2026
@gnugomez that would also be something useful to work on. We should tell the frontend what the maximum supported extension size is, e.g. via the existing
/api/versionendpoint that the frontend already fetches. If the user wants to upload an extension larger than the allowed max size, already prevent the extension from being uploaded.Currently, the upload happens no matter how big the extension is, and will then fail if the server reads more than allowed bytes.
gnugomez commentedon Jul 2, 2026
@netomi I'm not sure if using a dynamic value coming from the API here might be a good idea, also taking into account that this limit is not something that changes much, wouldn't it be better to consume an static constant that shares the same value as
ovsx.publishing.max-content-size?netomi commentedon Jul 2, 2026
but how do you inject that value into the frontend to make it aware of the limit the server enforces?
That is also some of the things that we might wanna change dynamically via runtime settings or make the size limit dependent on the publisher.
gnugomez commentedon Jul 2, 2026
I see also since it's configurable.
The only way to consume that statically from the frontend and make it configurable at the same time would be to add a page setting to the React app, so when you initialise the app it takes the value. But you would have to change that in both server and webui config...
Maybe it is something that we may want to retrieve from a settings endpoint then..
Why don't we move the GET /admin/settings out of admin?
I guess we could add a new value to the GET /api/version return, but doesn't that defeat a bit the purpose of the endpoint itself?
netomi commentedon Jul 2, 2026
/admin/settingsis for admin only and this is fine.we could make a new endpoint
/api/configthat includes things relevant for the frontend, e.g. version, upload limit, ... and remove the version one though.gnugomez commentedon Jul 2, 2026
yeah, that works, are we sure to remove the
/api/versionone?For health checks we have
/actuator/health. Are we sure there's no other consumer than the webui of this version?netomi commentedon Jul 2, 2026
we can add a redirect, the result currently would be extensible:
feat: prevent oversized extension uploads from the client
feat: prevent oversized extension uploads from the client (eclipse-op…