Allow custom prefix instead of q- for css classes (for built-in components, not custom)
-
I know how this could be achieved by making a few changes to quasar, i could’ve forked it and do it but I want to check if its built in since so far everything else I needed seemed to have been built into quasar.
-
No. There is no CSS obfuscation in Quasar.
Scott
-
@chey if you manage to have your extension installed than you can obviously do what you want, no level of client code protection will totally/absolutely/everytime protect said code.
if you want to use extension, I assume you need to obfuscate/hide this code, too. Fortunately, such extensions are prohibited- see here - obfuscated code not allowed:
https://blog.chromium.org/2018/10/trustworthy-chrome-extensions-by-default.htmlI consider your objections - in this specific context of course - as moot.
The question is, would it be to have a possible context, where obfuscation of client code would give greater security? Well, the practice and experience dictates, that such an effect is opposite in terms of security. Why? Because it gives people false sense of security. How? You know, that technically it is just not possible to protect client code from malicious use/reading/analyzing etc. So when you even slightly convince user, that there are even little security measuers independent from user actions, he will eventually make something which truly expose him to vulnerability. It is a user decision if he/she will allow to expose some specific functionalities (in example access to microphone) in specific context (this html page) and only at this specific time and place. If this decision is made, than it is a browser/os/network responsibility to not allow leaking data in those realms. For example if user allows use of his microphone, than she should be sure, that is is only one, specific microphone and not camera also, if she allows to use that microphone on specific html page, then browser should not allow to access this microphone from another tab, and the most important, if this data is transmitted to specific server, no man in the middle, be it another os process or router or anything, should be able to intercept those data. As you can see, obfuscation, in terms of security defined in above terms, is of no practical use.
-
The only reason you might want to hash css classes is to make the final bundle size the user gets smaller. And unless you are building some large app like Facebook or Googlemail, your gains will be minimal. Why waste time with something practically worthless, when you can be using that time to build something great, and if it does get big, you can worry about css size and obfuscation at that time?
Scott
-
Hi @s-molinari , checking back to see if you decided that obfuscation is worthy of your help
-
Sorry, I’m not the one to help you on this.
Scott
-
@s-molinari is there anyone you would recommend that I check with?
-
Not that I know of. Everyone I know, I believe, thinks like I do, that obfuscating code isn’t anything that is useful towards security. And, you most definitely don’t have a Facebook or Google Mail like application, so the benefits of smaller packages through obfuscation won’t be realized either. So, it’s a waste of time to chase a non-existent concern.
Scott
-
@s-molinari The 2 applications I’m working will need the class names to be smaller anyway, so even though I accept that client-side security methods like this wont really protect anything I’ll still need the obfuscation because one is an integrated form and document management platform and the other is a platform to handle communication from multiple sources from emails to site chats to Instagram DMs to Facebook comments and even SMS so I dont believe its fair to assume I dont a codebase that’s as big as a platform like Facebook or Google Mail just because I’m currently a “nobody”, I just didnt know how to word what I wanted properly and that the chrome extension incident in high school was a simple way to explain “systematic” renaming of classes to something different from whats in the source files.
-
This might help you on your way. https://medium.com/@my_own_grave/reducing-css-generated-by-vue-loader-by-using-classnames-shorten-trick-aa1d25d77473
Scott
-
That medium title tho haha, read the link about css modules, looks pretty neat. Will use that for sure, since scoped seem limited afaik.
-
What’s wrong with the title? @metalsadman
Scott
-
@s-molinari ah no i was wrong, notice it’s the author’s username.
-
Ah. Ok. Hehehe… my_own_grave. Yeah. That’s a riot.
Scott
-
@s-molinari would you agree that there should be a property of build in quasar.conf.js called obfuscate where when a “salt” for the “hash” is placed the JavaScript and CSS of the project is obfuscated when built? If you agree I’d be happy to work on it.
-
Nope. If anything, a CSS/ JS obfuscation system should be an app extension, which you can surely work on… to your heart’s desire!!!
https://quasar.dev/app-extensions/development-guide/introduction#Introduction
Scott