|
Not sure if this deserves being in the OP's frameworks section, but shout-out to d3.js for being an amazing data visualization js library that has made one of my recent freelance projects much easier and more enjoyable. Once you get used to d3's concepts, esp. the idea of entry sets and exit sets, the code is easy to write and really powerful. And thanks to the OP for all the links, will definitely check out the ones I haven't seen before.
|
#
¿
Jun 15, 2013 18:15
|
|
|
|
| # ¿ Apr 27, 2024 14:21 |
|
|
Not sure if web development is necessarily the place to ask about this but hopefully some people itt have run into this problem: My work has a growing collection of RESTful webservices implemented to try and move towards some kind of SOA. A recurring problem we run into follows this pattern: -Hey, service X returned a 500 in prod at 11:40 yesterday! -That's weird. I see a uniqueness constraint violation in the logs. What data did you send in? -We don't know. Don't you log that? Basically, our security team prevents us from blanket-logging all requests at the server level (including POST request bodies, etc.). They're afraid that this will result in PID & PII getting written to a logfile somewhere, which is a legitimate concern for the kinds of services we run. I presume it could also result in us getting sued because it writes a credit card number somewhere or something. Does anyone have an inspired solution to this problem that doesn't involve railroading security and could be used across multiple webservices undergoing rapid development? For instance, I could create a configurable logger in our service archetype that captured all request data but then I'd have to be concerned about some random developer not actually configuring it when they add their new /payments API. My gut feeling is that the easiest fix is to just to have the servers log all service traffic using a protected logfile with limited access to make auditors happy. However I have no clue if this is actually "a thing people do" and at the end of the day developers need access to it for debugging prod issues so I'm not sure what that limited access would actually mean in practice...
|
|
#
¿
Sep 20, 2014 18:08
|
|
|
Blinkz0rz posted:The PII stuff is what's going to kill you. I know whenever we deal with PII we have to follow FISMA regulations pretty closely. Log security is absolutely nuts. We're not government but we're large enough & have enough sensitive data for the people who make these decisions to (rightfully) err on the side of caution. I suspect that you're right and that logging PII with security restrictions is a losing proposition. But out of morbid curiosity what about log security is absolutely nuts? For example I would be totally fine with having some gatekeeper person who I could email and say "give me the full request for all http messages sent to X service at Y time yesterday, and if there's any PII fields in that request body then just don't send it to me and we'll loop in security." Also, I didn't mean to imply that there was one production bug I was trying to track down, it's more just that the pattern involves "some random edge case happening in production" and we lose what should be easy reproduction of the bug because a full log of the transaction data doesn't exist, regardless of whether PII was involved or not. We do eventually track down production bugs using tertiary information (who was in the system at that time, educated guesses, stack traces, etc) but it would save us a lot of time to have a systemic approach to service logging rather than the defensive approach we have now. Short term logging sounds like an interesting idea but I suspect that would still not fly with security, unless maybe there's some industry/legal standard I could point to. Which is totally possible, since I'm pretty unlearned in this stuff. TheresNoThyme fucked around with this message at 09:47 on Sep 21, 2014 |
|
#
¿
Sep 20, 2014 21:56
|
|