I created/maintained a popular project for years[^1], and recently passed ownership to someone else. It's been great seeing issues resolve, PRs merge, etc, after languishing for a while :)
The point is that with a powerful Effects system, devs calling the logger would have to account for the network call in their own code. Someone might have wondered why that was needed and gotten this addressed before it was ever widespread.
This class of bug (CSRF bypass via route confusion) is probably more common in Phoenix apps. I’ve found a handful of apps vulnerable to this issue with Sobelow.
People create (for example) a get ‘/profile’ and a post ‘/profile’, and the action intended to correspond with post requests really just pattern matches against params.
I’ve also seen at least one app implement this properly, matching against the HTTP method as you described.
Sure, the "passive" was what I was calling out as incorrect. And as you noted, a compromised trusted CA affects all domains. Which is another thing this article gets explicitly wrong.
> If DigiCert’s Key Management System is compromised, all of their SSL certificates will have to be revoked and re-issued. But if one of the other CAs is compromised, it would not affect Medium’s site.
This is a horribly misinformed article, and is incorrect about the most fundamental arguments it is making. E.g. Among many other issues, it implies that a compromised CA would allow passive MitM.
Agreed that you don't gain anything if you're using 1Password. But users may be required to set up MFA to access something like GitHub organizations, in which case having it available in 1Password is convenient.
I made the switch from web development to security a few years ago and initially took a 10-15% pay cut. I didn't get any certs and wouldn't necessarily recommend them. Instead, I joined various bug bounty programs to get practical (and resume-lite) experience.
Having implementation experience (via webdev) in addition to the bug bounty experience was a plus when I was interviewing.
If you're in a tech hub like SF or NYC there is plenty of security work. But, yeah, I would expect some kind of a paycut since you are moving from a (potentially) senior position to an entrylevel position.
I mean, I read the codebase, which is why I'm saying it's small and easily understood. Sure, it has some specific things to know, and some ("magical") helpers like automatic view functions. But it's no more its own platform than any other micro-framework.
I'd be interested to know what you believe the ups and downs are, aside from speed.
Phoenix is really a very small framework, and its codebase can be easily understood in just a couple of days. Phoenix being "large" is a common (but unfounded) criticism that seems to stem from Elixir's superficial resemblance to Ruby.