Vojtech Szocs has posted comments on this change. Change subject: restapi: Add CSRF protection filter ......................................................................
Patch Set 2: Small note, JScript is commonly referred to as Microsoft's dialect of the ECMAScript scripting language specification. JScript != JavaScript, both of them are implementations of ECMAScript standard, and each of them might include custom extensions to ECMAScript standard. (Juan's patch utilizes JavaScript engine based on Mozilla Rhino interpreter.) > we should have single mechanism to extend the engine, we are now working on > the extension interface for the engine which should provide single > methodology of extending the engine[2], one of the implementations can > delegate to jscript the logic. Alon, can you please post link for [2]? (in your comment, both [1] and [2] pointed to the same URL) If the planned Engine extension interface can support implementation based on JavaScript, why not just use JavaScript directly now, and update code (to comply with extension interface) later? Technically, you are right that Mozilla Rhino interpreter (or any other scripting language implementation) is optional within the Java SDK distribution.The Gentoo icedtea ebuild file you sent [1] contains "javascript" USE flag for this. According to [3], Mozilla Rhino interpreter is included only in Sun/Oracle JDK (including OpenJDK) by default. [3] http://stackoverflow.com/questions/4649519/jvm-missing-rhino/4649839#4649839 However, assuming we use OpenJDK for *both* development and deployment, Mozilla Rhino interpreter should be available for us. If we used some other Java SDK, we could still install Mozilla Rhino interpreter separately and make Java SDK aware of it, typically by putting its adapter files into /jre/lib/ext directory. So in general you are right, but in this particular case, I agree with Juan, I see no risk or overhead in utilizing OpenJDK's Mozilla Rhino interpreter for the purpose of customizing CSRF-related request trust logic. Simple netmask could be enough for some users, but having "isTrusted" function is far more flexible, plus it pushes the responsibility on writing actual trust check (based on netmask or whatever else) on user, so that we don't have to maintain/update specific (i.e. netmask based) logic ourselves. -- To view, visit http://gerrit.ovirt.org/26578 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I68f03eeefe5bcb1956036b4a80fef4400c467346 Gerrit-PatchSet: 2 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Juan Hernandez <[email protected]> Gerrit-Reviewer: Alon Bar-Lev <[email protected]> Gerrit-Reviewer: Barak Azulay <[email protected]> Gerrit-Reviewer: Itamar Heim <[email protected]> Gerrit-Reviewer: Juan Hernandez <[email protected]> Gerrit-Reviewer: Michael Pasternak <[email protected]> Gerrit-Reviewer: Sandro Bonazzola <[email protected]> Gerrit-Reviewer: Vojtech Szocs <[email protected]> Gerrit-Reviewer: Yair Zaslavsky <[email protected]> Gerrit-Reviewer: [email protected] Gerrit-Reviewer: oVirt Jenkins CI Server Gerrit-HasComments: No _______________________________________________ Engine-patches mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-patches
