More hellish complexity
this post was submitted on 21 Aug 2024
31 points (84.4% liked)
Programming
17378 readers
434 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
I love that you’re thinking about how to secure sensitive parts of JS applications, however I wonder what threat this is guarding against. Can you give an example? Surely if an attacker can modify the source to call the sensitive functions, then they could modify the allow list
I think it's is not aimed to protect against potential attacks, this is aimed at a developer using/writing modules of code. This is not a security guard
Ah ok, the name implies it’s a security guard
Excellent domain name!
I think its lacking of imagination
The idea is neat, and there is a certain precedent for the approach in .htaccess files and webserver path permissions.
Still, I worry about the added burden to keeping track of filenames when they get used as stringed keys in such a manner. More plainly: if I rename a file, I now have to go change every access declaration that mentions it. Sure, a quick grep will probably do the trick. But I don't see a way to have tooling automate any part of it, either.
Now that is ancient js style
I think similar, and arguably more fine-grained, things can be done with Typescript, traditional OOP (interfaces, and maybe the Facade pattern), and perhaps dependency injection.