Errors have become less informative

[Bob_Zimmerman]

I haven't been able to find an error schema anywhere, so I'm in the process of collecting tons of exemplars from different versions. I noticed today that if you specify a bogus domain when logging in on R80.10, it gives you a 400 status code with this body:

{"code":"generic_error","message":"Runtime error: Domain 'BogusDomain' not found!"}

Make exactly the same API call on R82 and it gives you a 400 with this body:

{"code":"err_login_failed","message":"Authentication to server failed."}

But it gets worse! When you specify the call against the R82 system should be run in APIv1.1 (R80.10's API version), it still returns R82's less helpful error!

To be clear: it looks like making a call against a previous API version does not ensure the call is processed the way the previous version processed it.

If anybody would like to reproduce this independently, here's the code I'm using:

apiVersions=("v1" "v1.1" "v1.2" "v1.3" "v1.4" "v1.5" "v1.6" "v1.6.1" "v1.7" "v1.7.1" "v1.8" "v1.8.1" "v1.9" "v1.9.1" "v2" "")
testBody='{"user":"PasswordUser","password":"1qaz!QAZ","domain":"BogusDomain"}'
for apiVersion in "${apiVersions[@]}";do
curl -ksv "https://${server}/web_api/${apiVersion:+/$apiVersion}/login" \
-H "Content-Type:application/json" -d "${testBody}" >curlOut 2>curlErr
<curlErr egrep "^(< HTTP|[^<>*])" \
| egrep -v "^([{}] \[|  Trying)" \
| sed -r 's@< HTTP/1.1 ([0-9]+) .+@(\1, Data("""@'
<curlOut jq -c .
echo -n '""".utf8)),'
echo -e "\t// API${apiVersion:- default version}"
echo ""
done
rm curlErr curlOut

[Timothy_Hall]

100% agreed, at least when using tools like mgmt_cli to make calls it will generally catch most syntax errors and give you some idea what is wrong.  But once you start making direct web API calls all bets are off. The only generic errors returned (with no additional details about the issue returned) for direct API calls are:

• generic_err_invalid_syntax (this one is the real killer)
• generic_err_session_expired
• generic_err_wrong_session_id

When teaching CCAS R81.20 on many occasions there will be a syntax error with a direct API call, and the only way to figure out what is wrong is to look at $FWDIR/log/api.elg or /var/log/gaia_api_server.log, and in rare cases $FWDIR/log/cpm.elg when the call makes it through the API server but then fails when executed by cpm.

Perhaps useful error messages are being restricted for a session that is not authenticated yet for "security reasons"?

[Bob_Zimmerman]

I get it, since telling someone that 2 out of 3 parts of their login request are correct narrows the problem space for an attacker.

That said, errors are part of an API contract. Changing them without changing the version number makes version numbers worthless. There are now at least two incompatible versions of the management API which both call themselves "v1.1".

The right approach would have been to stop claiming to support version 1.1 when the errors were changed.

[the_rock]

I will try test this in my R82 lab Monday.

Andy

[the_rock]

Just tested it, yep, exact same issue.

Andy