4 ms·
For security and possibly performance purposes, I would like to forego sending source maps to the client in Production and instead store the source maps, using
by Timothycquinn 9y ago
For security and possibly performance purposes, I would like to forego sending source maps to the client in Production and instead store the source maps, using versioning on the server and just send serialized client side stack traces to the server for error reporting. Has anyone done this before? I tried digging into this several times in the past but came up empty.
- untog 9y agoOne immediate issue that comes to mind: source maps aren't downloaded unless the user has the dev console open. Unless you have an answer for how you're going to detect that, any custom solution will be less performant than the existing solution.
- yesimahuman 9y agoYes, this works identically. You would need a sourcemap library like source-map for JS or libsourcemap for python. Instead of having the browser load the sourcemap you just load it in the library and map stack frame line:col for the corresponding file. We have an exception service for for our company that relies on private sourcemaps and this is our approach.
- bretthoerner 9y agoI could be misunderstanding your question, but the Sentry JS SDK sends exceptions to the server and they are unminified on the server side. The server will attempt to download the sourcemaps automatically, but you can also disable them in production and push them to Sentry manually (when you deploy). So this this gives you one existing option, and at least shows it's possible if you need a custom solution.
- paulddraper 9y agoAt Lucid (https://www.lucidchart.com https://www.lucidchart.com), we've used a home-grown solution that stores the versioned source maps in S3, and decodes the stack traces server-side and adds it to the original trace in the logging system. Plus caching the decoding. We've looked at Sentry and might use that. They offer hosted and open-source on-prem solutions.
- Timothycquinn 9y agoSweet. Sounds like what I am looking to do. Server side should be pretty straightforward. Is your client side code homegrown of do you use an OSS JS framework?
- paulddraper 9y agoWe use Closure Library. It has some error handling code.
- prawks 9y agoI often hear people point to security as a reason to avoid shipping sourcemaps in Production, but it seems like such a non-issue given that anyone can unminify the code shipped out to their browsers. What kinds of secrets are able to be hidden via obfuscation? The answer traditionally is "none" so I'm pretty consistently baffled. We do strip comments explicitly so that devs don't need to be as concerned with exposing anything that way, but aside from that I don't really understand this angle.
- paulddraper 9y ago> What kinds of secrets are able to be hidden via obfuscation? Source code is very effectively hidden by obfuscation. If that were not true, GNU and open-source and GPL would not exist. --- Regardless, another important thing is not to download source maps onto client's machines, as that defeats the whole point of minification. Decoding stack traces server-side dedups work and doesn't impose an unnecessary performance burden on users.
- WorldMaker 9y ago> Regardless, another important thing is not to download source maps onto client's machines, as that defeats the whole point of minification. Browsers don't download source map files unless the developer tools are opened. If your client is using your app with the dev tools open you may have other problems that have nothing to do with performance.
- fny 9y agoAh, good ol' security via obscurity. I bet they don't want you to know about `var SUPER_SECRET_ENCRYPTION_KEY = ` or the inner workings of some crappy client DRM. The only case where I'd think it makes any sense is for protecting programming work from simple replication. While it isn't particularly hard to break client-side security bogus, its difficult to turn a minified mess into comprehensible code.