The idea of deprecating allow-deny has been gaining a bit of traction in several channels, but at this point it is just an idea. That being said, the deprecation discussions have been centered around how much allow-deny should be further supported / promoted by Meteor, when in its current form, it can be quite easy to misuse. I think we can all agree that the functionality behind allow-deny has definitely proved its value in Meteor. The outstanding question is, however, what can we do to improve allow-deny functionality, to make it safer to use and easier to understand, while at the same time retaining its powerful capabilities? That’s where the deprecation discussions have been headed; how can we progress this paradigm?
Putting all of this aside however, Meteor is definitely committed to backwards compatibility. Even if it was decided that allow-deny in its current form should be deprecated, it would still remain part of Meteor core (e.g. like the deprecated spiderable package). It would no longer be under active development by MDG, but it would still be usable as is (and can always be extended as a local package). Given that allow-deny functionality hasn’t really changed in years, we should be alright …
So just to re-cap; allow-deny in its current form might be deprecated at some point in the future, but that will only happen if there is a better solution to replace it. The exciting takeaway from all of this is - what does a better allow-deny look like? How can we make this awesome part of Meteor, that was likely one of the main reasons we started using Meteor, even better?
Given that allow-deny functionality hasn’t really changed in years, we should be alright
At least for me, “deprecated” means that we cannot rely on bug fixes and since we are talking about a mechanism that, when used, is a vital part of the systems security, then I do not think that we can be “alright” if it is being deprecated.
I think the problem here is that the “deprecated” label can mean different things, based on the context it’s used in. In the case of allow-deny, “deprecation” would mean that its use is no longer recommended (which is the case now), it’s no longer being actively developed (has pretty much been the case for years), and won’t be accepting or implementing new feature requests (I’ve seen one allow-deny FR in the past couple of years). The version that exists currently would continue to work (and would still be part of the Meteor core), but it wouldn’t be taken further. Given that allow-deny has been such an integral piece of the Meteor infrastructure pie however, if it was deprecated I’m pretty sure it would still have critical issues resolved. Meteor is an active open source project, and pull requests are reviewed/accepted weekly. If a bug was found in allow-deny and a PR was submitted, even if it was deprecated, I’m pretty sure it would be accepted. This has happened with other Meteor core deprecated packages, so there is precedent.
All of this sums up what I meant by “we should be alright” .
But just a reminder - at this point all talk of deprecating allow-deny is just that, talk. Nothing has been made official, and a deprecation decision wouldn’t be made lightly (or without more community involvement/discussion).
Yes, but words are important. If I’d, as a consultant, would develop something for a client and that clients security officer comes back with “Hey, you are using deprecated methods in the security mechanism, you must change that!”, then it probably helps very little to say “Well, it is deprecated because it is so good and secure that they will not need to develop it anymore”
You know that could, and would, happen. Somewhere. One day.
The word ‘deprecated’ also commonly has the connotation with an intended discontinuity. As in: “Please find another way of doing this because we intend to remove the capability in the next functional version. If you don’t you will not be able to migrate to the new version”. Because of this, in my view we shouldn’t use the word deprecated when that is not the case, like when saying “Blaze is deprecated”.
