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
This issue is similar to #208, and mentioned there, but seems worth filling separately for clarity.
Certain updates will leave the edge in an insecure state, even though a security module is configured for the entire duration.
For example, after creating an ngrok edge, a change that tries to replace OIDC with OAUTH will apply without any changes to the serving status of the backend. However, while the change is being applied, the edge will have neither OIDC nor OAUTH configured, and thus may route unauthorized requests.
This is made worse by the fact that changing from OIDC to OAUTH will actually error out terminally, and thus the edge will just be left insecure forever in the above scenario (until a human operator deletes it, or revers the change, or takes some other action).
What you think should happen instead
When an update occurs, the update should be atomic such that either the old or new config applies (i.e. when changing from OAuth to SAML, every request should observe one or the other, not neither or both at once).
The text was updated successfully, but these errors were encountered:
euank
changed the title
Endpoints are left in insecure states during creation and some updates
Endpoints are left in insecure states during soem updates
Jun 26, 2023
euank
changed the title
Endpoints are left in insecure states during soem updates
Endpoints are left in insecure states during some updates
Jun 26, 2023
What happened
This issue is similar to #208, and mentioned there, but seems worth filling separately for clarity.
Certain updates will leave the edge in an insecure state, even though a security module is configured for the entire duration.
For example, after creating an ngrok edge, a change that tries to replace OIDC with OAUTH will apply without any changes to the serving status of the backend. However, while the change is being applied, the edge will have neither OIDC nor OAUTH configured, and thus may route unauthorized requests.
This is made worse by the fact that changing from OIDC to OAUTH will actually error out terminally, and thus the edge will just be left insecure forever in the above scenario (until a human operator deletes it, or revers the change, or takes some other action).
What you think should happen instead
When an update occurs, the update should be atomic such that either the old or new config applies (i.e. when changing from OAuth to SAML, every request should observe one or the other, not neither or both at once).
The text was updated successfully, but these errors were encountered: