All mocking is now broken in latest Adobe 2021 and...
# adobe
l
All mocking is now broken in latest Adobe 2021 and Adobe 2023 FYI
n
@lmajano Can you share the repro case or the link where we can check the issue ?
d
@lmajano The args being required for remote methods change is only documented for the cf2025 update. Are you saying it's actually in the 2021 and 2023 updates too? Or is this another issue?
r
Are they remote methods?
Yeah, I'm not a fan of that change. It broke all my tables using DataTables.net.
d
Apparently it's a security issue though. We might enjoy having our doors and windows unlocked, but it's not generally good practice ๐Ÿ™‚ Arguably it does block some pretty valuable coding patterns, but only for remote methods.
r
Yeah, I'm not looking forward to adding 60+ argument declarations on some of the methods though.
๐Ÿ‘ 2
r
The feature can be turned off via
-Dcoldfusion.runtime.remotemethod.matchArguments=false
. The issue I have with it is that even when the function isn't being called remotely it enforces the argument matching.
d
One alternative to declaring a ton of args is to instead declare and pass a single struct argument. For example:
Copy code
function validateOneRow(required struct stValues)
Where stValues is typically the whole form scope, maybe with other stuff added, removed, or changed.
The problem with using the jvm arg to shut that check off is that it leaves you open the vulnerability this change intends to fix.
r
For sure. There are other vulnerabilities addressed in the update though, so it's better to update and set that flag than to not update at all. It at least gives some time to get code updated to work appropriately
d
Agreed
For the record, we are seeing moderately widespread problems in dev, TBD if they're so bad we want to shut this behavior off for now.
l
Yes, they are in 2021+. In reality, this is heavy handed, and intrusive
The whole point of a dynamic language is to allow for dynamic arguments.
Regardless of the visibity of a function
If you really want to lock down a function, then provide it as a way to pin point do it via annotations or markers. But not, lock everything remote because we feel itโ€™s more secure
@nimitsharma This is the issue, basically TestBox Mocking is now broken because of this, as it relies on dynamic arguments, as the mocking service can be called directly or remotely
I would really be interested to see why this was done and what was it trying to prevent.
Because this from the release notes makes no sense:
This change ensures stricter method integrity and a better debugging experience
b
@lmajano, just to be clear, is the new flag
-Dcoldfusion.runtime.remotemethod.matchArguments
the cause of the issue?
For completeness: answered 'yes' by @lmajano elsewhere.
m
I believe it should have been defaulted to
false
. I would argue that generating an error gives an attacker a method to discover the contours of your remote methods. Silent removal of such things is our policy. To be clear, not publishing or ":hiding" special method arguments is not secure; but your app should be handling that anyway. What if a network appliance or service between the browser and ColdFusion adds a query parameter. Would you have to strip it in
Application.cfc
? +1 dynamic arguments. There is a jvm arg but again defaulting to
false
would have made this less painful.
d
But by default that would have left sites open to the exploits this is trying to prevent.
l
What exploits The only thing this can expose is unscoped variables with scope Hunting issues
The problem is creating major Breaking changes on patch releases
If you want to break it. Break it in a major release
Anyways. I added the argument so TeatBox passes. The rest is up to Adobe.