Is https://bam-cell.nr-data.net missing from the CSP docs?

Sometime on Oct 13-Oct 14 2020, I am seeing a new URL at bam-cell.nr-data.net which appears to be the endpoint for error reporting.

This is a new domain which is not whitelisted by my CSP and is not on the CSP doc https://docs.newrelic.com/docs/browser/new-relic-browser/getting-started/compatibility-requirements-browser-monitoring#csp

Is this a documentation issue or a misconfiguration?

2 Likes

Hi @royz,

Good catch and yes, we will be temporarily using bam-cell.nr-data.net for some accounts, so if you’re using CSP whitelisting it should be added. We’re working on getting the docs updated.

Can you please inform the affected accounts (or just everyone) before making similar changes in future? We had entire teams jump on what appeared to be a serious production issue for half a day since we lost all New Relic metrics from the frontend due to this one.

Thanks!

@Robin.Osborne I can understand how frustrating and stressful this situation has been and we appreciate the fair feedback. As @hwilkalis mentioned, we are currently updating our documentation to reflect the change.

@nmcnamara I appreciate you’ve now updated the documentation, but as per the suggestion of @Robin.Osborne, this is something that people should be aware of before you make the change. They shouldn’t have to look at the documentation for something they’ve already configured to know that something has been changed on the New Relic end.

Cheers!

@nathan.jones1 I completely get where you’re coming from and your feedback makes complete sense. I have flagged this internally to try and prevent this from happening under the radar again.

1 Like

Just my “plus one” for active notification for these types of changes. It has taken us a couple of weeks to track down the reason our browser reporting vanished. We even have a ticket in with NR support but we eventually tracked it down ourselves. Getting our CSP updated in production is going to take some time. It would have been better if we could have done that more proactively.

@jshelby I appreciate you sharing that. And you’re right, there seems to be a lot of trouble that could have been saved with a bit more proactive communication. The frustration here is not lost on me.