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

Feature request: Rollback untrusted API calls #2203

Closed
ejulien opened this issue Nov 22, 2018 · 2 comments
Closed

Feature request: Rollback untrusted API calls #2203

ejulien opened this issue Nov 22, 2018 · 2 comments

Comments

@ejulien
Copy link

ejulien commented Nov 22, 2018

Hello,

Context: Our editor can be extended using plugins. Plugin hot-reload+ImGui is extremely fast to iterate with.


Problem: Unfortunately API misuses are really ruining our party. These come in two flavors:

  1. Genuine errors (eg. wrongly scoped End or EndChild call).
  2. Script errors interrupting an otherwise valid sequence of ImGui calls.

Both usually end with a C++ assertion being thrown which is less than ideal.


Solution?: Both scenarios can be adressed in the same manner but solving the first one might be more work.

Handling scenario 2. could look something like:

ImGui::EnterUntrustedSection();

bool success = call_plugin_issuing_ImGui_calls());
if (!success)
    ImGui::RollbackUntrustedSection();

ImGui::ExitUntrustedSection();

if (!success)
    ImGui::Text("So sad");

Script execution failure was reported by the client code but that doesn't cover API misuse.


The ideal version would validate the untrusted section on exit and roll it back if it did not pass.

ImGui::EnterUntrustedSection();

call_plugin_issuing_ImGui_calls(); // alea jacta est

if (!ImGui::ExitUntrustedSection())
    ImGui::Text("So sad");

Obviously logic already executed in the client code can not be rolled back (eg. if (ImGui::Button) ++my_var;) but that really doesn't matter. As soon as the error is repaired the UI will correctly reflect those changes anyway.


While not a critical feature to have I wonder how hard it would be to implement on top of the current design?

@ocornut
Copy link
Owner

ocornut commented Nov 22, 2018

Linking to #1651. Could you copy your exact post in #1651 and I'll merge the issues?

We'd be to be very specific about what use case exactly we are trying to fix/rollback.

Let's also be clear that we are never going to be able to correct 100% of the bad use case, nor prevent intentionally malicious users from crashing your app or messing up with your state.

But I agree that if we can fix 90% of the common use case that would be progress for any users of scripting language.

@ejulien
Copy link
Author

ejulien commented Nov 22, 2018

Done. Sorry, I did not manage to find #1651 when looking for duplicate.

@ocornut ocornut closed this as completed Nov 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants