RayGun IP Range?

We'd like to publish sourcemaps but only make them available to our office IP and to RayGun. Is there a static range of IP addresses that the RayGun services operates from that we can whitelist?

If the sourcemaps were only for consumption by RayGun we would likely just send them to you but we'd also like to make them available to our developers for in-browser debugging on production servers - but not otherwise available the the public. So it makes sense for us to publish them with our app.

If you don't have a fixed IP range that we can count on, we could always publish them both to the app and to RayGun, it's just some added work.

Also, while we're on this topic - if we were to upload sourcemaps to RayGun, how would you distinguish between different versions? Meaning do you just take the "latest" sourcemaps that we deploy per Application and apply them against subsequent errors?

Hi Ryan,

Sourcemaps uploaded to Raygun must be labeled with the URL they would usually be accessed from, thus if your files are labeled with a URL that includes a version eg. http://example.com/js/myapp-v1.1.min.js or http://example.com/js/myapp-v1.1.min.js.map the correct JavaScript and Map files will be used (so long as the files triggering the error are also versioned).

Files labeled with identical URL's are not allowed within the source centre so only a single file is allowed for any URL. For this reason uploading files via the API endpoint with identical URLs results in the old file being overwritten.

Feel free to contact me via email if you have any further questions.

Best regards, Alex

alex@mindscape.co.nz

We version by query string parameter, eg: version 1.0.0 -> http://example.com/js/myapp.min.js?100 version 1.0.1 -> http://example.com/js/myapp.min.js?101

Can we upload sourcemaps for each of these script versions?

Yes that will work.

So we've looked into sending sourcemaps to RayGun in an automated way but this just isn't feasible for us. At build time on our CI server we know the build number but not the end URL where it will be deployed (could be on a variety of hostnames). Unless we could provide a wildcard like "*.example.com/js/app.js?12345" for build 12345 - but this doesn't seem possible.

So we're back to the whitelisting IP ranges. I see requests from you currently coming from 54.242.21.245. Is this reasonably persistent or is there a range of addresses?

Hi Ryan,

Yes that is currently where sourcemaps will be requested from.

At the moment we don't support wildcarded URL's but this can be overcome by making the filenames reported to Raygun consistent by attaching a beforeSend handler after initializing the Raygun4Js provider.

An example of this is provided at the bottom of this page: https://raygun.io/docs/workflow/source-maps

Best regards, Alex

Sorry to hijack the thread but it's related... we're evaluating migrating to Raygun from Sentry precisely because of private source maps.

Having to push the source map files to the Raygun servers using the provided API is a bit of a pain actually. Since filtering by IP range is not possible, what about allowing the use of HTTP Basic authentication when requesting the sourcemaps (or any other resource you might need from the application server)? This should be technically trivial to implement on the Raygun service and also trivial to implement on the application servers.

Here is how I think it should work:

• User defines on Raygun's application admin panel an username and password to use on any requests performed by Raygun.
• User configures its application web server to require authentication with those credentials among any other access rules she wishes to implement (ie: allow access from office IP range).
• Raygun will always include the HTTP Authorization header with those credentials when requesting a resource from that application.

Since the Authorization header will always be sent (if the user configured the credentials), on the application server we can directly deny access to those private resources (with a 404 for instance) without even exposing the 401/403 responses if we don't want to for whatever reason.

"Can you elaborate on why it's a pain?"

Sure, these are the main reasons:

• it requires changes on the build script which often times is already a really complex beast :)
• pushes our IP (intellectual property) to your servers (unminified source code), which I can agree is a moot point but I work in a big corporation so these things take a lot of effort to get approval.
• we already support publishing the sourcemaps on our servers with a restricted access policy (office IP range)
• minor: requires access to your servers from our build server (corporate firewall and its absurd rules)

In essence the current solution is not very friendly for "corporate" clients, if we were a smaller company I would have no problem integrating with the API, in fact I would probably have no problem publishing the source maps without any access restrictions at all :)

I completely get your points though, I shouldn't have used the word "trivial" to refer to this, you're right that many times changing a single line of code involves much more than just the coding effort.

thanks!