I would like to make a simple web calculator to allow some field technicians to enter numerical data into it and calculate a result. The problem is that the page will be hosted publicly, though our calculations are something we'd like hidden from outside interests. Is there a way to hide the formula or call an outside script so we don't expose our methods to people who may want to inspect the .html file?
I have experience writing basic HTML but am far from a web developer. Please give links or detailed instructions if possible. Thanks in advance.
If the calculations will be done in the browser, then the code to do the calculations must be sent to the browser. If the browser can figure it out, so can a person.
If you are really serious about hiding your algorithm, you should probably create a service that runs on a server that you control. The web page would collect the inputs, send them to the server and respond with the outputs from the calculation.
EDIT:
Welcome to StackOverflow!
If you want your calculation algorithms executed on the client, you're out of luck. Anything you send to the browser must be considered "open". The only method of hiding anything is obfuscation, and that is usually easily undone.
If hiding your algorithms is more important you will need to have a server that performs the operations and exposes an API for the client to access. (EG: Client says "hey server, calculate X for me" the server performs the algorithm with X and sends back the answer)
There's no way to do this with Javascript inside of a html file. You can minify or obfuscate which can help a bit. This can make the Javascript harder to read or understand but it's relying on security through obscurity, in other words, if someone is determined enough they can figure out what's going on.
The best way to solve this is to set up a server that does the calculations. A client webpage can send a request to the server and return the results, while preventing people from seeing how it's done. This is how Google keeps it's search function private despite returning the results.
Related
Hi I'm new to dynamic web dev. I've searched this site but couldn't find anything similar.
I want to implement a password checker, for robustness and length etc. Fairly conventional. The thing is, I have 2 options: 1. embed javascript inside an HTML. 2. embed javascript inside a jsp file.
With a little preliminary research it seems that most people recommend the former, that is to go with HTML. I wanna know why? I could be completely wrong, in that case I also wanna know why?
The "how" isn't all that important, but "why".
Edit: I know this question is full of flaws (for example JSP and HTML aren't mutually exclusive) but please indulge me a little bit and tell me which scheme is more appropriate, if I want to get things done front end, in a user's browser.
Edit#2 : Sorry I did not provide any bg information: I am working on a larger project and password checker is just a part of it, the project itself is a dynamic web project relies predominantly on java, serverlet.
As you state you are new to dynamic web dev. JSP is a server side programming language Just like PHP and others. If you want to confirm password, you can use ajax to check for a match from your database and if match was found create a session and redirect your user to the logged in page. If i misunderstood your question, please try to be clear enough.
Depends on your use-case. In some cases, just the front-end is enough. In many, I would say both is better.
By putting it in the front-end/client-side (the "HTML"), you create a more user-friendly approach, since you can rapidly and continuously evaluate the users' input and give them feedback.
If the application doesn't need to be particularly robust from a security perspective, this can be plenty.
The downside of HTML only validation of any user input is that it can easily be bypassed. As a programmer, I could figure out what its doing and easily bypass any and all client-side protects. Users can also wholesale just disable JavaScript, so if your site works without JavaScript in general, they won't get any validation. This is why "security" on the client side is never a thing. Never trust the client.
Implementing it only on the back-end/server-side ("JSP"), you can lock down the security since the end-user can't bypass any of your validation. It must match the rules you set forth.
The downside to server-side is that you must send the data to the server to be analyzed, then wait for a response. While this may be fast, its still much slower than client-side.
By doing it in both, you get the best of both worlds. You get the rapid feedback for the end-user without having to send any data to the server, and you get the full protections of making sure it is properly validated on the server-side.
The downside to this of course is you have to double-up on your code, so its more effort. That's why you want to weight the pros and cons in your particular case, as there isn't a single "best" answer.
If the HTML is enough for you - why should you use .jsp?
You need .jsp for creating dynamic content and it's gonna be compiled as Servlet - do you actually need Servlet in this case?
If security is not a big concern then HTML + javascript should be fine. It will be responsive amd lead to better user experience.
If this is an external facing application on the web then as mentioned in some of the other answers go with Jsp approach.
I am a newbie game maker that making some web games with the language of JS, HTML and CSS. But the problem is i can't prevent the right click inspect hacking thing, so a people hacked my games by using this method.
My question is, how can i prevent this method to not to being hacked...
Here is my game http://ozansiar.com/mario/oyunok.php
Here is the score page http://ozansiar.com/mario/skorekran.php
as you can see it can be hacked...
Language is Turkish, sorry for not doing this in English, but i will.
Second question is, how can i improve my game developing? I heard that phaser is a good engine, so i'm doing a research for reach to some tutorials. But also, i need some good advices from you...
Sorry for my newbie questions, but i do need some good advices to improve my web development and also game development skills... Thanks so much!
Note : Games are made by what i learned from stackoverflow community... So also thank you very much for this.
Client-side code (HTML, CSS, JavaScript) is called "client-side" because it is downloaded to the client and executed there. There is absolutely nothing you can do to protect this code from users seeing it and modifying their local copy of it. Even storing your JavaScript in an external file and linking to it does not solve the issue. The same is true with obfuscation.
All protected code should exist on a secure server and execute there in a "server-side" architecture, such as .aspx, .PHP, .jsp, etc.
So I just ran through the game and "hacked" it. The problem you have is that you use forms and hidden inputs to send the game results to the server, first when the user finishes the game you submit the time it took them, then on the second page you send their final score in a hidden input. Both of these can be easily modified by the user before they're submitted.
What you could do is create a checksum of the hidden values that you don't want the player to modify. After they're posted to the server, use the values to re-calculate the checksum in PHP, and if it doesn't match the checksum submitted by the browser, don't accept it.
This won't stop people from hacking your game, but it will make it more difficult. If they absolutely want to fake their score, they can look up the javascript function you use to generate the checksum on the client side and use that to generate a new one with the values they want, so it's not 100% secure.
As for the final score, I'd suggest you use a session for that. Your skor.php file generates a form with the final score in a hidden input. Why? Just dump it in a session property, and read that back in skorislendi.php. That way, the user won't be able to edit it.
You can't prevent the client, i.e. the player, from hacking client side materials, i.e. client-side scripts, HTML and etc... Any legitimate actions that your scripts perform on the client side can be faked. At best, you can mitigate such hacks by obfuscating your JS code and post data. This makes it harder to hack but doesn't save you.
In the end, ask yourself this one question. Is security essential to my game? If it is, then worry about it. Otherwise, build what you can and from an agile point of view, add features, such as security, when NECESSARY.
I'm just now tapping into real GUI-heavy stuff and I'm looking to integrate a GUI for a Python 3 application/("game"?). I need this to be cross-platform, responsive, and able to communicate with other users and a server.
I've looked at desktop application creation but I think that the best thing would be a web application. Now, here are the obstacles:
I need the web app to be able to use all my Python 3 code as its black box; it needs to be able to send a function call to the running python code.
More often than not, everything on the page is changed if a single value is changed.
If another user changes a value, it would affect multiple other users instantaneously.
I can't have the page constantly refresh.
The HTML "GUI" needs to have some degree of separation from the Python code. (I can't have Python sending snippets of HTML, only data is allowed.)
I realize that this is a lot to address, so my question then is:
How would one go about making a web app that has specific (most) data values update consistently without having to refresh the entire page?
My proposed solution would have some sort of simplistic javascript constantly checking to see if anything has been posted for the users closely interacting with each other (players in the same server, if you will). Each value in the HTML would have a linked javascript function which is linked to a value or function in the backend python code.
"Player" changes value on webpage -> JavaScript function call -> Python black box on "Server" -> JavaScript checking loop sees that there has been a change via simple Python variable on "Server" -> JavaScript gets all values via calls to functions in python code -> Update HTML for all "Players"
Finally, please note, I have no idea how to carry out my proposed solution, and I very much welcome a different, better approach. Thanks in advance.
So, for anyone who is trying to do the same thing as me, the answer is something called "websockets".
I initially tried Kivy, but found that it was too cumbersome and just hard to get good styling in. Using HTML, CSS, and JavaScript, you can make pretty fancy looking stuff, and Kivy just isn't robust enough to make something attractive without having to write tons of excess code. Since what I'm trying to make is basically a styled data readout/hud, the HTML combination takes the cake.
What I'm currently using for the websockets is a module called "Tornado" which allows you to update any data on the client side without them reloading the page. I'm sending this data as a single JSON to update the whole page.
In conclusion, I decided on HTML/CSS/JavaScript for the GUI and Python/Tornado for fast server-side computation.
With all the recent hype about JavaScript and HTML5 replacing Flash, I wanted to know - How would it be possible to protect client-side js code? Of course, it is possible to obfuscate it, but that would only make it a little harder. Also, for games which submit high scores to the server, wouldn't it be incredibly easy to modify those scores before they are sent to the server? I know even Flash files can be decompiled, but they can be obfuscated and flash decompilation is not as easy as modifying data in JS - could be done easily using a plugin such as Firebug. I'd like to know everyone's views on this.
Javascript, being parsed on the client, is never 100% safe. There will always be ways to find out what it does. A few days ago I've even seen a tool which unpacks packed javascript so the only thing you can really do is using "ugly" variable names (or actually, make a javascript packer transform your "good" variable names into short/ugly/nonsense ones)
To protect game results, you have to move some of the game logic to the server so the client cannot send arbitrary results.
Summarizing it: Don't put secrets in javascript code and don't trust anything coming from the client - no matter if it's from a form or generated/submitted via javascript.
You say that for game that sends high scores to the server it would be too easy to modify javascript and forge request?
Except for case, when you use some cryptography on the client, it is the easiest way to forge such request not even analysing the script but sending false request itself. Everything you send between server and browser can be easily viewed on computer, analysed and changed.
looking for some general advice and/or thoughts...
i'm creating what i think to be more of a web application then web page, because i intend it to be like a gmail app where you would leave the page open all day long while getting updates "pushed" to the page (for the interested i'm using the comet programming technique). i've never created a web page before that was so rich in ajax and javascript (i am now a huge fan of jquery). because of this, time and time again when i'm implementing a new feature that requires a dynamic change in the UI that the server needs to know about, i am faced with the same question:
1) should i do all the processing on the client in javascript and post back as little as possible via ajax
or
2) should i post a request to the server via ajax, have the server do all the processing and then send back the new html. then on the ajax response i do a simple assignment with the new HTML
i have been inclined to always follow #1. this web app i imagine may get pretty chatty with all the ajax requests. my thought is minimize as much as possible the size of the requests and responses, and rely on the continuously improving javascript engines to do as much of the processing and UI updates as possible. i've discovered with jquery i can do so much on the client side that i wouldn't have been able to do very easily before. my javascript code is actually much bigger and more complex than my serverside code. there are also simple calulcations i need to perform and i've pushed that on the client side, too.
i guess the main question i have is, should we ALWAYS strive for client side processing over server side processing whenever possible? i 've always felt the less the server has to handle the better for scalability/performance. let the power of the client's processor do all the hard work (if possible).
thoughts?
There are several considerations when deciding if new HTML fragments created by an ajax request should be constructed on the server or client side. Some things to consider:
Performance. The work your server has to do is what you should be concerned with. By doing more of the processing on the client side, you reduce the amount of work the server does, and speed things up. If the server can send a small bit of JSON instead of giant HTML fragment, for example, it'd be much more efficient to let the client do it. In situations where it's a small amount of data being sent either way, the difference is probably negligible.
Readability. The disadvantage to generating markup in your JavaScript is that it's much harder to read and maintain the code. Embedding HTML in quoted strings is nasty to look at in a text editor with syntax coloring set to JavaScript and makes for more difficult editing.
Separation of data, presentation, and behavior. Along the lines of readability, having HTML fragments in your JavaScript doesn't make much sense for code organization. HTML templates should handle the markup and JavaScript should be left alone to handle the behavior of your application. The contents of an HTML fragment being inserted into a page is not relevant to your JavaScript code, just the fact that it's being inserted, where, and when.
I tend to lean more toward returning HTML fragments from the server when dealing with ajax responses, for the readability and code organization reasons I mention above. Of course, it all depends on how your application works, how processing intensive the ajax responses are, and how much traffic the app is getting. If the server is having to do significant work in generating these responses and is causing a bottleneck, then it may be more important to push the work to the client and forego other considerations.
I'm currently working on a pretty computationally-heavy application right now and I'm rendering almost all of it on the client-side. I don't know exactly what your application is going to be doing (more details would be great), but I'd say your application could probably do the same. Just make sure all of your security- and database-related code lies on the server-side, because not doing so will open security holes in your application. Here are some general guidelines that I follow:
Don't ever rely on the user having a super-fast browser or computer. Some people are using Internet Explore 7 on old machines, and if it's too slow for them, you're going to lose a lot of potential customers. Test on as many different browsers and machines as possible.
Any time you have some code that could potentially slow down or freeze the browser momentarily, show a feedback mechanism (in most cases a simple "Loading" message will do) to tell the user that something is indeed going on, and the browser didn't just randomly freeze.
Try to load as much as you can during initialization and cache everything. In my application, I'm doing something similar to Gmail: show a loading bar, load up everything that the application will ever need, and then give the user a smooth experience from there on out. Yes, they're going to have to potentially wait a couple seconds for it to load, but after that there should be no problems.
Minimize DOM manipulation. Raw number-crunching JavaScript performance might be "fast enough", but access to the DOM is still slow. Avoid creating and destroying elements; instead simply hide them if you don't need them at the moment.
I recently ran into the same problem and decided to go with browser side processing, everything worked great in FF and IE8 and IE8 in 7 mode, but then... our client, using Internet Explorer 7 ran into problems, the application would freeze up and a script timeout box would appear, I had put too much work into the solution to throw it away so I ended up spending an hour or so optimizing the script and adding setTimeout wherever possible.
My suggestions?
If possible, keep non-critical calculations client side.
To keep data transfers low, use JSON and let the client side sort out the HTML.
Test your script using the lowest common denominator.
If needed use the profiling feature in FireBug. Corollary: use the uncompressed (development) version of jQuery.
I agree with you. Push as much as possible to users, but not too much. If your app slows or even worse crashes their browser you loose.
My advice is to actually test how you application acts when turned on for all day. Check that there are no memory leaks. Check that there isn't a ajax request created every half of second after working with application for a while (timers in JS can be a pain sometime).
Apart from that never perform user input validation with javascript. Always duplicate it on server.
Edit
Use jquery live binding. It will save you a lot of time when rebinding generated content and will make your architecture more clear. Sadly when I was developing with jQuery it wasn't available yet; we used other tools with same effect.
In past I also had a problem when one page part generation using ajax depends on other part generation. Generating first part first and second part second will make your page slower as expected. Plan this in front. Develop a pages so that they already have all content when opened.
Also (regarding simple pages too), keep number of referenced files on one server low. Join javascript and css libraries into one file on server side. Keep images on separate host, better separate hosts (creating just a third level domain will do too). Though this is worth it only on production; it will make development process more difficult.
Of course it depends on the data, but a majority of the time if you can push it client side, do. Make the client do more of the processing and use less bandwidth. (Again this depends on the data, you can get into cases that you have to send more data across to do it client side).
Some stuff like security checks should always be done on the server. If you have a computation that takes a lot of data and produces less data, also put it on the server.
Incidentally, did you know you could run Javascript on the server side, rendering templates and hitting databases? Check out the CommonJS ecosystem.
There could also be cross-browser support issues. If you're using a cross-browser, client-side library (eg JQuery) and it can handle all the processing you need then you can let the library take care of it. Generating cross-browser HTML server-side can be harder (tends to be more manual), depending on the complexity of the markup.
this is possible, but with the heavy intial page load && heavy use of caching. take gmail as an example
On initial page load, it downloads most of the js files it needed to run. And most of all cached.
dont over use of images and graphics.
Load all the data need to show in intial load and along with the subsequent predictable user data. in gmail & latest yahoo mail the inbox is not only populated with the single mail conversation body, It loads first few full email messages in advance at the time of pageload. secret of high resposiveness comes with the cost (gmail asks to load the light version if the bandwidth is low.i bet most of us have experienced ).
follow KISS principle. means keep ur desgin simple.
And never try to render the whole page using javascript in any case, you cannot predict all your endusers using the high config systems or high bandwidth systems.
Its smart to split the workload between your server and client.
If you think in the future you might want to create an API for your application (communicating with iPhone or android apps, letting other sites integrate with yours,) your would have to duplicate a bunch of code for all those devices if you go with a bare-bones server implementation of your application.