Hello guys!
I tried viewing the source page of my web application and I found information which reveals a lot about the structure of my source code. Is there a way I can totally hide all the information? With this exposed, my application isn’t secured. I was even able to see my python code in the browser.
My understanding is that client-side code is always available if users want to inspect it, so I don’t know that there is a way to hide it.
The server-side code on the other hand is invisible to users, so that is where you will want to put details that relate to security.
This is just the nature of web applications - code that runs locally in the user’s browser is always visible to the user and can be altered by them.
This is why it’s important that client-side code should only be concerned with the presentation layer of the application - placement of forms, button, widgets etc. - and anything else should be executed on the server side. The most the user can then see is the names of the server side functions being called.
Thanks for all your responses. I do understand that client side code can be viewed and modified by the user. However, I don’t think it’s a good idea to display my client side code as plain text Python code. If Anvil converts Python to JavaScript, it would make more sense to display the generated JavaScript code than my Python code as it is in my source code.
Displaying my app’s HTML, CSS or JavaScript code is okay. I just worry that if the user can see my Python code as it is in my source files, then they might be able to replicate my app or do worse.
In theory, someone could replicate your app even if it is in another language. In fact, they could replicate your app (in most cases), by simply using it without looking at the source code at all. As mentioned by @owen.campbell this is the nature of web applications regardless of the language. That is my understanding anyway.
Anvil uses Skulpt. Skulpt transpiles Python to JavaScript at the browser. No doubt this is so that some of the supporting Python code (e.g., GUI, browser-specfiic code) can be generated on-the-fly as needed.
However, it should not be necessary to transmit comments or docstrings, nor should it be necessary for the browser to hold on to the Python source afterwards, except in the IDE.
I expect that the technology will improve as it becomes more popular. We should see “obfuscation” and “minifying” tools for Python webcode, just as there are for JavaScript.
It’s true anybody can replicate an app just by using it, I get that. I just don’t want someone to see my app’s Python source code.
Let’s take for example, I have an app that requires users to have a license before they can use it. Upon successful login (Or say during login), I check if the user’s license has expired (check is done by a server function that returns True or False). If license not expired, user is granted access, otherwise, access is denied and user is prompted to renew license.
The check is done on the server and the return value is then compared on the client’s browser. If a malicious user is able to see the point where the validity of his/her license is checked, what’s stopping them from always making that condition to True? Hence having unauthorised access to my application.
Quick question: Users can see my client Python code, can they modify the Python code? I know JavaScript, CSS and HTML can be modified, I’m not so sure about Python.
Obfuscating / minifying the python code would make it slightly more difficult and decrease the number of unauthorized accesses by a just few percent. There are more hackers able to figure those things out in javascript than in python - skulpt - javascript.
You CAN do the check on the client side if you need to hide or show a button or any other UI element.
You should NEVER allow unauthorized access to anything just because in an earlier round trip the server told you that you are authorized.
Anything sensitive will eventually go through the server, for example to store something in a table. That’s when you will need to check for authentication and permission. Then, if the server finds out that a hacker tried to trick the client into believing that you are authorized, the server will respond with an unauthorized error message.
Agreed. The effect they would have on a determined, well-resourced hacker, would be minimal. A speed bump, at best.
If you have any interest in stopping, or at least slowing, less-dedicated groups and individuals, too, e.g., the merely curious or slightly mischievous, then such tools may yet be of use.