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.
Related
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 hosting a small service where people can create online calendars. I'm playing with the idea of allowing users to save & embed their own javascript/html/css to their calendars.
I'm a bit worried about the security implications - are there ways to use XSS etc so that the users javascript code could affect some other calendars besides the one where the code is embedded?
From the customers perspective, the JS on the page should be allowed to change all the aspects of the page.
I guess the safest way would be to only allow custom HTML/CSS, but the ability to modify the layout and functionality of the calendar with JS would be a nice feature to have.
This can be very dangerous, for the same reason that
eval is evil
You're basically giving the user an oportunity to run malicious scripts.
Example: You are using AJAX to update something on your server. I come along, open up my trusty Firebug, see the AJAX request, and decide to wreck a little havoc, because thats what I do. I just rewrite the AJAX call, change the id of my calender to some random one, and bam, thats my dirty deed for the day.
When I say "Vanilla Coding", I am referring to websites that don't utilize server side coding (such as PHP, ASP, etc.), only HTML, JavaScript, and CSS.
I know that there are a plethora of sites that already exist that don't utilize (to my knowledge) any of the common, server side languages used by many others (PHP, ASP, etc.), but still function just fine!
I am confused! How do these sites continue to save login information, keep records, etc. etc. without using a server side scripting language? Is there something that I am missing? Can JavaScript access more (such as databases and local files) than what I thought it could?
EDIT
Turns out I've made a serious and shameful mistake in assuming that just because it ended with a .html extension that it was client-side only. That is okay though because I'm learning. Thanks so much for the help everybody!
Essentially, unless you have some sort of server-side programming, you don't stand a chance at making a site with any amount of functionality. To break it down for you:
What you can do without server-side scripting:
Serve static pages
What you need server-side scripting for:
Absolutely everything else
Even something so simple as keeping a site consistent and up to date is a nightmare on wheels without, at the very least, some some sort of management system that pre-generates the static pages to be served. (Technically, one could argue that Copy+Paste in Notepad counts as this.)
As has been mentioned elsewhere; obfuscating the true nature of precisely what system is being used is trivial; and having URLs ending in, say, .html while using PHP is no issue.
Edit: In the most perverse case I can think of off the top of my head, you could have a lighttpd server masquerading as an IIS server, serving pages generated by an offline renderer fed to it by a Perl FastCGI script, sent together with PHP signature heading and using a mix of .asp and .jsp file extensions.
Of course, noone would do something as silly as that. I think…
No client side script can access server side information (like a database) without some sort of server side communication (through something like ajax or the like)
If you really ( i mean really as in don't do it ) want to do logins and the like on clients side, you would have to make some sort of cookie that you store on the user's computer, also you would need a list of users (which anyone can read) to use against
This answer is very late but I leave this reply for anyone who may stumble upon it.
Using javascript/jQuery, and various APIs a simple site can be created only using client-side coding.
For instance, a simple shopping cart type of site can be created. I've done it before.
There are few (not many) strictly 100% jQuery based shopping cart solutions that are open-source.
How does the PG (pay gateway) get taken care of? You are limited to accepting payment through paypal, google checkout, and direct deposit.
What about allowing customers to leave comment? You can use API's like Disqus. What about chat support? Zopim is pretty handy.
How do you get notified when purchase is made? Paypal & google checkout notifies you.
What about sending mass email? Mail Chimp.
Personally, I almost always use WordPress or some other types of CMS but using only vanilla coding to build a simple site is not only feasible but very sensible in certain circumstances.
You're not going to see whether a site is using a server side language unless they let you see the file extensions. With URL rewriting, MVC patterns, etc., it's easy to hide, or even fake that information. Therefore, chances are very good that the sites that you think aren't using a server side language are actually using one.
Now, a site can save certain information in cookies, such as some basic preferences, but any authentication they appear to be doing wouldn't actually be doing anything without a server-side script accessing a database somewhere.
As a side note - I have worked on a site where the content was actually static, but made to look like a blog or CMS. It was an absolute nightmare and hugely error-prone.
What are these sites that you think aren't using server-side scripting?
Nowadays a lot of sites are using Javascript as a server side solution, Node.js being the most popular. Check out this list: https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
I'm thinking of implementing my web application in a certain way as an optimization, and I'd like to get people's opinions on whether this is a good idea or not.
Here's the details:
For most of my pages, instead of determining server side whether the user is logged in, and then modifying the page I send based on that, I want to send the same page to everyone, this way I can make use of my reverse caching proxy and for most requests not even have to run any dynamic code at all.
The differences that need to be done for logged in users will be done in javascript. The necessary information to make the changes (what their user name is, their user id, and if they are logged in or not) will be stored in a cookie that can be read by javascript.
I don't need to worry about the users not having javascript because my web app requires javascript to be used anyways.
Only the most popular pages that are accessible to both logged in and logged out users will do this.
What do you guys think? Pros/cons? Is this something that websites commonly do?
Doing it for 100% of your application would be a little problematic, however, it sounds like you are seeking to use something called the Model-View-Presenter pattern:
http://en.wikipedia.org/wiki/Model_View_Presenter
Be wary that, when using javascript, your code is exposed, meaning that any security measure taken is potentially hackable through the browser. Add protection on the server side and you are set.
Also, since you are going to rely heavily on javascript, I really recommend you using Mootools, which is an object-oriented approach to javascript. That way you can keep your code really modular, work around messy implementations using custom and class events, etc.
Major con: If you are determining what content a viewer can access with JavaScript alone, it stands to reason that a malicious user can potentially access premium content with just a little glance at your source code.
I'm not sure what you are optimizing really - you need to fetch the user data anyway, and only the server has that. Do you plan on sending an AJAX request requesting for data and using javascript to format it? you are only saving on output generation which is usually not the bottleneck in web application. Much more often the database / IO (files) / network (HTTP requests) are the bottlenecks.
The major con here is that by moving all output generation to javascript, you will increase substantially the download size and reduce overall responsiveness. Since none of the big sites use this approach, you can be sure it doesn't solve scalability problems.
It has been long time since we have been validating our forms using JavaScript. I am sure this must be the case with most other developers.
Question:
What if the user (or probably a bad guy) disables JavaScript?
You are lost!
Is JavaScript validation worth of it?
Should we ever use it now?
Are there any solutions to this?
Correct me if I am wrong.
Is JavaScript validation worth of it?
Yes, as it provides a better user experience and preserves bandwidth.
Should we ever use it now?
Yes, for the aforementioned reasons.
Are there any solutions to this?
Yes, use server-side validation as well.
What if the user (or probably a bad guy) disables javascript?
As said before: Simply do not rely on the client. Never do so. Check everything on the server again.
Should we ever use it now?
Yes - so the user immediately sees what's wrong. Otherwise he had to post back the data first which may take a while. By the way you reduce traffic to your server.
It's simply more inuitive.
//EDIT:
BTW: The ASP.NET ValidationRules contain both client-side and server validation as far as I know.
Javascript validation is good because it provides a better user experience.
You should however never rely on it and should validate on the server regardless.
If you're looking to save time, go with server-side only. If you want better performance and user experience, add client-side validation afterward. Never rely on client-side validation, for the reasons you state. All critical validation should occur on the server ... even if duplicated on the client.
JavaScript improves user interaction for your product or service. Users interaction (user input and machine response or vice versa) is a vital characteristic of our applications. As we all experienced, products are getting more interactive ever than before. And this interaction part can (only) be crafted in JavaScript (ActionScript for Flash Player). We would all agree with this - there is always a calculated amount of work that can be transited to the client side (machine) to avoid calls without bothering them to send to the server(s). There are many many applications which are heavily dependent on client-script scripting. And if they found you do not allow required scripting they asked for it leaving a message in noscript tag. But I think everyone wants to have it enabled as we all fire up a tab with Gmail, Facebook, etc.
However, this still should not be ignored as we are keen to grap every single opportunity (audience/customer) and work with is at least better than falling apart. It still works!
As a Microsoft Development Platform user, there is a convenient solution on .NET platform. That don't require dual effort on such issues. Make use of your client-side validation while scripting is disabled by using Page.Validate() and Page.IsValid.
protected void Page_Load(object sender, EventArgs e)
{
if (Page.IsPostBack) {
Page.Validate(); // If you missed, then you got the second chance ...
}
}
protected void btnSubmit_Click(object sender, EventArgs e)
{
if (Page.IsValid) { // Confirm you do a proper validation before moving to perform any process
Response.Write("Done!");
}
}
I hope this will help.
Client-side (Javascript) validation is about usability, nothing else. If the cost of implementing is not worth the perceived increase in usability, then don't spend the time on it. These days it's pretty easy to do though!
I don't think you can do without server-side validation, however, since this is the only thing that provides you with any security.
Using JavaScript is not wrong. We've been using it since a long time. It is used for applying client-side validations.
Still, we should implement server-side validation so that a bad guy would not be able to break the application.
If you learn only one thing from this topic, let it be this:
Never — under any circumstances — trust data from the browser and always validate request data on the server-side.
Should we ever use it now?
Yes, definitely. You do not need to validate an empty field on the server side. It is not something like validating an email's availability (uniqueness of email). If you are going to reject that empty field anyway, there is no point of sending it to server and making
server do extra work for it.
You have to validate it on sever-side, javascript is good to validate form, but people can disable javascript, or use another javascript to hack it, so validation on server-side is a must.
JavaScript is useful for client side validation. But you cannot rely only on them. You must use server-side validation against the posted data. JavaScript just prevents unnecessary posts to the server.
You can make server and client-side validation pretty painless by using a framework that supports both. In the past, for ASP.NET I used the Peter Blum validators:
http://peterblum.com/
With this, you drop the validation controls onto your page, hook them up to the inputs (textboxes, drop down lists etc), and specify the validation properties (minimum length, required, error message etc). When the page runs, the framework spits out equivalent code for both the client (JavaScript) and server (ASP.NET) to perform your validation.
Without such a framework, as other posters have pointed out, validation can be laborious.
I'd be interested to know of anything similar for PHP or other technologies.
You should have multiple layers of validation.
Validation on the client Side
This is definitely useful because validation can be done without having to go to the server. Requests get to the server once they are validated - saves some traffic.
Validation on the server side
If javascript is disabled then the server should also incorporate a level of protection - validation in order to disallow erroneous requests.
In a multi-tiered / service orientated environment validation should exist on multiple levels to allow for better reuse while still maintaining a secure application. Validation on the client side, whether in a desktop app, or web site/application should be there for a better user experience to prevent postbacks to the server everytime for validation, hence costing more bandwidth and user time. If client-side validation cannot be moved entirely to the front end then consider using ajax for a partial postback to a server side validation routine, while retaining a better customer experience but allowing a programmer to maintain the validation rules centrally.
Second to the client side, but more importantly, server side code should validate the data before persisting it via a data layer or passing it to another server side method/service, to employ business rules around the data and help prevent errors in data integrity. Lastly, the persistence layer itself (the immediate interface to the database or other storage mechanism) should validate the data being stored, again to prevent errors in data integrity and possibly further business rules. The last thing you want is a data store with useless data.
Employing this method will keep you data secure and integrity in line. On reuse of either you persistence layer, your data layer or your front-end presentation thereafter, in your own site (or via a web service, desktop application or mobile app), if designed properly, these validation routines are already in place and can be re-employed. This should prove to be of great benefit to you alone, and your colleagues and your management, if you happen work in a team.
Is JavaScript validation worth of it?
well,yes it is .Buy using JavaScript validation you can easily take any kind information about client site more over JavaScript validation provides a better user experience
Should we ever use it now?
Yes you can because of user can see there error or what's they do wrong on real-time
Are there any solutions to this?
yes you can also use server-side validation.But sometime its take more time .it's also insecure
Javascript is a client-side scripting language. Therefore we can use client-side validations by using it. It helps to reduce the load that goes to the server-side. That's why js validation is worthy. And that is the reason for use it for client-side validations. But we should not only depend on js validations. Because the client can turn off the js engine at any time. If so, it causes a big problem.