5 ms·

At some point, mvc frameworks have to do some magic to dynamically load classes. This should be done at runtime, but can’t imagine it’s an easy problem to solve

• richbell 5y ago
  Frameworks like Quarkus and Micronaut do this at compile time. They dynamically load things and record it, then insert the resulting bytecode statically in the build artifact. I believe the core motivator is performance, but it has the added benefit of eliminating most of the runtime magic that leads to vulnerabilities like this.
• dboreham 5y ago
  Not my field, but how can this be so? We had MVC in 1990 written in C or C++.
  • olliej 5y ago
    In principle I think you could do something like this with COM, but I’m unaware of any such framework
• olliej 5y ago
  No they don’t, MVC has existed in C++ for decades. The problem is specific to reflection based MVC frameworks (objc has similar issues). The solution is to explicitly specify every class that can be instantiated at compile time. Similar to how modern deserialization frameworks work. No code should be written that allows content from the network to explicitly specify arbitrary code to load and execute. E.g having a packet say <view class=“MyView”> and feeding the string “MyView” into some classloader, or dlsym, or whatever is asking for trouble. Feeding it into switch (view.class) { case “MyView”: return new MyView() … } Results in a much less powerful primitive