Suggested pattern for sending to server that proxies on to Stackdriver

[trevtrich]

Our policies won't allow us to have an api key directly in our calls given that we can't lock down an api key to only the Stackdriver Errors API. Do you have any recommendation for shaping these errors so that we can "proxy" them through our app engine server? You've done a fair bit of work in getting this shape right prior to shipping it up to the api directly, so I'd like to leverage that, but I'm not seeing a great way of doing that without just pulling out the code into my own module.

[steren]

Indeed, this is a known limitation of API keys. This is why we recommend creating a dedicated project only used for this purpose.

I know many customers who forward the errors server-side, and then simply log them.

I would encourage to contribute to this module and add this use case.

The stackdriver-errors-js file is about catching errors, transforming them and then sending them to the Error Reporting API. Only this last part needs to be changed.
In practice only the url variable of the sendErrorPayload needs to be different.

This URL could be something that is part of the config object.
The user would then be in charge of implementing this endpoint server-side.

Bonus point: we could also provide a Google Cloud Function implementation of the endpoint.

What do you think? I would gladly accept your contributions, reviewing your Pull Request and collaborate.

[trevtrich]

Excellent, appreciate you being open to it. I'll start putting something together.

[skjolber]

@richardson-trevor I now see an 'API restriction' called 'Stackdriver Error Reporting API' when editing the API key. @steren is this considered safe if used together with the proper 'Application restrictions', without creating dedicated projects?

[trevtrich]

Didn't realize that I had never come back to comment on this. There's now a config value available for sending to a custom target url: https://github.com/GoogleCloudPlatform/stackdriver-errors-js#configuring-without-an-api-key.

[trevtrich]

@skjolber if you were looking for something that does proxy to one of your controlled servers that has access to the Stackdriver api, the link I dropped above should explain how to do so. This has been working well for us for a few months now.

@steren if you're satisfied with the solution, I believe this issue can be closed.

[skjolber]

@richardson-trevor thanks for the quick response, was the 'API restriction' called 'Stackdriver Error Reporting API' not available previously? Is your current solution open-source, and/or does it handle Config Maps privately?

[trevtrich]

Ah, okay. I missed your point in the first message. I think our issue was that we were trying to create an api key that was purely limited to the Stackdriver Error Reporting API and we couldn't do so at the time. The reason we wanted to do this was because we didn't want to open up any other permissions since our package was getting shipped to browsers and therefore would've been a major security issue. Since our current implementation works well, we haven't come back to check if it would now be possible to lock down an API key to only the reporting api.

[steren]

I was not aware that API restrictions were available.

API restrictions specify which APIs can be called with this key.
No API restrictions. This key can access all APIs enabled in this project.

It seems that this solves the problem. I will update the README with this suggestion.

@richardson-trevor can you help me confirm that using this restriction mechanism does what you were looking for?

[trevtrich]

I think the major things that threw me were things like this:

Note: Do not use API keys for local or production applications, except in the specific cases described below. For almost all cases, you should use service accounts.

and

A limited number of GCP services allow access using only an API key:
Google Cloud Natural Language API
Google Cloud Speech API
Google Cloud Translation API
Google Cloud Vision API
Google Cloud Endpoints
Google Cloud Billing Catalog API
Cloud Data Loss Prevention API

These come from https://cloud.google.com/docs/authentication/api-keys

[trevtrich]

Even with this, though, our team's needs were satisfied with the earlier mentioned configuration ability to proxy errors through our application servers, which has worked quite well for what we wanted. This way we don't ever have to leak a key to the browser.

[skjolber]

Ok, thanks a lot guys! 👍 @richardson-trevor @steren