Add it as part of your app, if you need it, when you need it, how you need it? 
josevalim
Creator of Elixir
BartOtten
Unfair. Could be said for everything 
Phoenix is a batteries included framework, not a low level lib or language. We get Auth, we get a login screen, we get a reset password screen, we could get….
But it seems settled
0
josevalim
Creator of Elixir
Most of the release for v1.8 was exactly in trimming down what we generate because it was clear that it was generating too much, getting in the way of both experienced devs (generating stuff they didn’t want) and new ones (too much to grasp at once). So there is a clear trend we are aiming for when it comes to generated code.
It is already exhausting to be in the forums and getting to constantly hear about everyone’s wish list. And on top of that, getting eye rolls, called weird (another thread) and unfair. When maintainers get characterized negatively for making decisions aligned with project goals or when simply sharing their opinion, it makes it harder to justify spending time in these informal discussions. So overall it is probably best for me to keep some distance and not get involved unless through official proposals.
12
hubertlepicki
BartOtten
I get that. I sometimes just speak open over wishes, but there are no hard feelings when they are not granted. For me this was a “exploring” discussion pushing back a bit. Sorry if it sent the wrong message. Love and respect for the hard work you and the rest of the team do.
0
BartOtten
Just to be extra clear about my standpoint:
Developers are not obliged to respect anyones wishes, nor to fix bugs, not to fix docs, nor to discuss feats etc etc in software which is free to use and especially when one can contribute (or fork in extremes).
Developers sometimes might feel they are but they are not. Just have to remind ourselves so every once in a while.
2
garrison
Even a tiny timing difference can be surfaced by making enough requests and then comparing on average - similarly, you cannot “hide” a record by adding a random offset because enough requests will reveal the mean (I’m sure you know this, but maybe others don’t).
But when looking up a record in a DB you’re usually hitting an index, which should make it considerably harder to figure out whether the record actually exists. The btree lookup will still make it all the way to the last page before discovering whether the record is there or not, and the timing should be roughly the same I would think.
If there was no index (a full sequential scan) and the record in question was in the middle you would have a much more pronounced difference, of course.
This is nice to hear, running phx.gen.auth was indeed quite overwhelming. I implemented my auth by hand following phx.gen.auth (it’s a great example), so I actually know (knew) how it works exactly line-by-line. It took a while…
1
garrison
I feel like this point got lost in the discussion, but it’s very important. Hiding a user’s record from the public internet is not security through obscurity. It’s not even security! It’s privacy! You should avoid exposing any of your users’ private information by default.
Information is only transferred when you deviate from your standard response. If you always return 404 when a page is not found, then returning 404 for a private record confers no information about the record.
Similarly, if you play poker and you always maintain your standard poker face, you confer no information about your hand. But if you have a tell, regardless of what that tell is, you confer information about your hand!
0
BartOtten
True. But it is still information: that the requested resource does not exist.
Hiding a user’s record from the public internet is not security through obscurity. It’s not even security! It’s privacy! You should avoid exposing any of your users’ private information by default.
This was not the point. The point is if we should fake ‘non existent’ or use the standard response code “403: you are not authorized to access the resource” (or 401: you are not authorized at all, regardless of the specific resource)
My standpoint is “don’t fake it does not exists when it does as it confuses good people too and violates web standards we all value so much since IE ”, the other standpoint is “fake it does not exist so it’s existence is obscured from bad people; good enough reason to violate the webstandard”. To the latter I reply: obscurity won’t matter when a non-junior hacker targets your app for real, according to quite a few hackers in the company I work at.
2
garrison
No, it does not confer that either. I suppose you could say it confers “this website has a 404 template”, if you wanted to.
But the problem, as discussed with the git example, is that some routes are public unless you don’t have access. So if you try to load up a public repo you can see it, but if you load a private repo it has to 404. If you 401 for the private route then you admit that it exists.
You could instead return 401 for repos that actually don’t exist, but that is even more confusing!
0