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

Don't ignore secure field on devfile endpoints #22676

Open
amisevsk opened this issue Nov 17, 2023 · 1 comment
Open

Don't ignore secure field on devfile endpoints #22676

amisevsk opened this issue Nov 17, 2023 · 1 comment
Labels
area/che-operator Issues and PRs related to Eclipse Che Kubernetes Operator kind/enhancement A feature request - must adhere to the feature request template. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. severity/P1 Has a major impact to usage or development of the system. team/A This team is responsible for the Che Operator and all its operands as well as chectl and Hosted Che

Comments

@amisevsk
Copy link
Contributor

Is your enhancement related to a problem? Please describe

Currently, setting secure: true on an endpoint does not add authentication to that endpoint, despite the devfile API documentation stating

Describes whether the endpoint should be secured and protected by some authentication process. This requires a protocol of https or wss.

This means the field is misleading, as setting it true or false doesn't change anything with respect to auth.

Describe the solution you'd like

As suggested by @l0rd in issue #22664 (comment), we could treat secure: true endpoints in the same way as endpoints with urlRewriteSupported: true (i.e. serve such endpoints through the main gateway):

  • If secure is true on an endpoint, treat that endpoint as though it had urlRewriteSupported: true
  • If an endpoint has secure: true but urlRewriteSupported: false, either warn the user that the secure field is being ignored in this case (as we cannot secure such endpoints) or fail the workspace.

We would need to be careful around making this change as it would potentially break existing endpoints in workspaces -- I don't know a good way to avoid that.

Describe alternatives you've considered

No response

Additional context

See issue: #22664

@amisevsk amisevsk added the kind/enhancement A feature request - must adhere to the feature request template. label Nov 17, 2023
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Nov 17, 2023
@l0rd l0rd added severity/P1 Has a major impact to usage or development of the system. area/che-operator Issues and PRs related to Eclipse Che Kubernetes Operator team/A This team is responsible for the Che Operator and all its operands as well as chectl and Hosted Che and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Nov 20, 2023
@che-bot
Copy link
Contributor

che-bot commented May 18, 2024

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 18, 2024
@tolusha tolusha added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/che-operator Issues and PRs related to Eclipse Che Kubernetes Operator kind/enhancement A feature request - must adhere to the feature request template. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. severity/P1 Has a major impact to usage or development of the system. team/A This team is responsible for the Che Operator and all its operands as well as chectl and Hosted Che
Projects
None yet
Development

No branches or pull requests

4 participants