3 ms·
So you're better off rolling your own auth gem vs utilizing a popular gem that's been baked in thousands of production environments? I agree that Devise is hea
by aantix 13y ago
So you're better off rolling your own auth gem vs utilizing a popular gem that's been baked in thousands of production environments?
I agree that Devise is heavy and hard to extend but when we're considering such a fundamental like auth, you have to have a pretty good reason to deviate from the time tested popular choices.
Maybe you can write a lighter auth class, but can you write a more secure auth class? If devise has a vulnerability, there are tons of other sites out there "watching your back" and could report the vulnerability. If you roll your own, how are you going to aggressively audit its security?
- aantix 13y agoAbout 10 years ago, I remember a guy that interviewed that bragged that he wrote his own linked list class instead of using the one the STL used. I was amazed and impressed at the time. Now that same statement would totally set off red flags and he'd be a non-hire (unless I could personally audit the code). Maybe he provided more syntactic sugar so his implementation was easier to work with? And if that's the case, why not just build on top of the standard implementation? But if he claimed a performance increase, is that for the general case or for some specific case he was coding for? Deviating from the standard library is a bold claim that has to be backed up by a code audit.
- rubiquity 13y agoI think you're overstating the security value that Devise gives you. It's hardly more than Rails gives you out of the box. After all, Devise is for Rails and written in Ruby.
- aantix 13y agoI think you're underestimating the power of utilizing a community built library.