Forcing Autotask to Return with 500 Status Code for Application Specific Reasons

A quick question for which I haven't been able to find docs...

It seems that Autotask does some helpful black-boxing for HTTP responses. We just return a result and it's wrapped in the standard Autotask return body:

How can I make Autotask return a 500 for application specific reasons? For example, I want to return a 500 when authentication of an X-Authorization header is improperly signed.

As it is now, I reject a promise in my async function and return the error. However, this still shows up as a status: 200 and data.status: success.

Here's the code if that helps:


The reason this is important: dev-prod parity.

When devving locally in a docker-compose environment, I've been running the same main.js function used in prod, but wrapped in an Express POST handler. So with that, I return a 500.

Maybe I should just have this POST endpoint always return 200 like in prod? Not sure.

Also, the result field that I have returned from the Autotask is a string rather than JSON. Am I doing something wrong or is this expected behavior?

Hi @flaco_jones, I understand your scenario and it makes sense. We need some time to think through this.

An HTTP status 5xx signals a server error. In this case Defender acts as the server and if you throw from Autotask code it still means the request resolves successfully, so signaling error at the HTTP layer might not be an adequate solution (we'd be crossing layer boundaries so to speak).

Regarding the result field, that is expected behavior, you can read more details here:

@flaco_jones, can you share some more details of what type of authentication mechanism you're trying to use?

As I mentioned above, we don't want to allow user autotask code to control HTTP status code, but we are exploring ways of providing the ability to perform auth checks, so you can control how end users interact with your Defender resources.

So we're interested in hearing from your specific scenario :).

Thanks for getting back so quick @MartinVerzilli

We are passing a signed GitHub OAuth token on the X-Authorization header and unsigning it manually (using a COOKIE_SIGNER secret) here:

BUT! No big deal, since as of now I just JSON.parse(response.result) and use the error I throw to determine the status code on our proxy server:

Don't want ya'll to cross layer boundaries. I know how dicey that gets :slight_smile:

1 Like