Thank you for your reply ? . Is there an example, on the forum, of Javascript code made purely on the server side..Or you write your code purely on the server side like PHP (=jServer/ABM), or you do it on the browser side (=JavaScript/BANano). Most WebApps are kind of hybrids where all the 'secret' stuff (database, credentials/access and refresh tokens) are on the server side, all the common things (UI interaction for example) are on the browser side for speed.
I found this post in the forum : https://www.b4x.com/android/forum/threads/abmaterial-b4js-00-introduction.90249/ which I think is yours in a series of toturials on B4JS. It seemed a quite good point to start from for writing JS code on the server side..Or you write your code purely on the server side like PHP (=jServer/ABM), or you do it on the browser side (=JavaScript/BANano). Most WebApps are kind of hybrids where all the 'secret' stuff (database, credentials/access and refresh tokens) are on the server side, all the common things (UI interaction for example) are on the browser side for speed.
And also:Having the browser doing some stuff using Javascript can have some advantages by relieving some pressure from your server (checking if a form is filled in correctly, or changing the visibility of an ABMcontainer if a user clicks a button). But it also demands a great resposibility from the programmer not to expose to much information to the user. Never, ever write sensitive stuff like SQL, passwords etc in B4JS!
So, is the lack of secrecy a vulnerability or a limitation in jServer use that can be worked around?And also:
Never assume that the client code, client cookies or anything else coming from the client, wasn't hacked, copied, tampered or modified in any possible way.
Sorry I meant the use of any relevant tool (like jServer) through javascript to make a web app not the jServer itself.Nothing in this thread is specific to jServer.
jServer code runs on the backend and is secure.
This times 1000. Never, ever trust input from the web. Always sanitize it first before using it. In Perl you can specify a special mode (taint mode: https://www.geeksforgeeks.org/perl-taint-method/) that would not allow you to just use user supplied data. And as has been mentioned above, this has nothing to do with your JavaScript code. Please note: A user does not have to go through your web page in order to feed bogus information to your web server. They can (and do) use automated tools to do that. You can use JavaScript to catch input errors on the client side, therefore cutting down on server side trips for checking input data as the user enters it. But, once the data is sent to the server, you should always re-check the data with server side code. Always.That's true.
You cannot trust anything that comes from the client, including any output of your JavaScript code that runs on the client.
How would you do that in Javascript?You can use JavaScript to catch input errors on the client side, therefore cutting down on server side trips for checking input data as the user enters it. But, once the data is sent to the server, you should always re-check the data with server side code. Always.
So I will try writing the Javascript code on the server side.It's pretty meaningless to obfuscate code running in the browser. Don't do it, it's just a crutch giving you a false sense of security.
100%It's pretty meaningless to obfuscate code running in the browser. Don't do it, it's just a crutch giving you a false sense of security.
A question:100%
As I said in that obfuscator thread there shouldnt be anything in b4jws.js that is a secret or needs protecting. It is just a JavaScript to communicate with the backend. The backend should implement checks against the users session eg are the signed in, are they who they say they are etc. There is little point is obfuscating javascript as it can easily be decoded.
But seriously, have you looked at the code in b4jws.js? Its 50 odd lines. Its there to do a job which it does. Dont change it. Dont add stuff to it. Dont try and "secure it".
Any event handlers (ie subs in the web socket handler) that it can call need to have sufficient security checks in them. Fiddling with the front end is a very bad idea and is not secure.
Those of us who have worked in software security say that it is one more level of security.It's pretty meaningless to obfuscate code running in the browser. Don't do it, it's just a crutch giving you a false sense of security.