What's the best way to validate controls, client-side JavaScript validation or server-side validation?
As others have said, you should do both. Here's why:
Client Side
You want to validate input on the client side first because you can give better feedback to the average user. For example, if they enter an invalid email address and move to the next field, you can show an error message immediately. That way the user can correct every field before they submit the form.
If you only validate on the server, they have to submit the form, get an error message, and try to hunt down the problem.
Server Side
You want to validate on the server side because you can protect against the malicious user, who will probably know how to bypass your JavaScript and submit dangerous input to the server. The server should never trust input from the user, no matter what validation you've tried to do on the client side.
Server side validation is also important for compatibility - not all users will have JavaScript enabled.
Source JavaScript ClientSide vs. ServerSide Validation
The .NET validators work both client side and server side.
This is best practice, as you want the responsiveness of the client side, but the security of the server side (as you should never trust the client - always validate on the server as well).
For example - with tools like firebug, javascript may be active, but the script can be easily tampered with (so it "passes" validation on the client, even if it shouldn't). Your server side code is not exposed to the client, so you should always also validate on the server side.
both
javascript validation helps you to save serverside traffic and the user doesn't have to wait, because he gets immediate feedback. but users can deactivate javascript, so you need serverside validation as a backup.
Both. Client-side for quick feedback to the user without needing to postback. Then again on the server-side, because client-side validation is easily bypassed.
Related
I am confused about client side and server side validation in ASP.net.
I know that client side validations validate on the client side, and asp.net validation controls are server side controls. But if I am applying it on any server side control like <asp:textbox> and apply RequiredFieldValidator, it validates immediately like a client side control. All other asp validation controls validate immediately without post back to server.
So how does it work without posting back to the server?
Even though the ASP.NET server theoretically validate on the server, they will also validate on the client. From Microsoft's documentation:
If the user is working with a browser that supports dynamic HTML
(DHTML), ASP.NET validation controls can perform validation using
client script. Because the controls can provide immediate feedback
without a round trip to the server, the user experience with the page
is enhanced.
Under most circumstances, you do not have to make any
changes to your page or to the validation controls to use client-side
validation. The controls automatically detect if the browser supports
DHTML and perform their checking accordingly. Client-side validation
uses the same error display mechanism as server-side validation.
If you use HTMLHelper in the views it will automatically insert javascript validation from e.g. the DataAnnotation of the model. Things like Required, MaxLength etc. are checked on the client-side (and on the server-side again).
I have a system which uses Jquery AJAX calls to an .ASMX web service for INTERNAL and STATELESS use.
For example, after pressing a button, a Jquery call is launched to insert a new user).
Now, the problem is, that the Jquery AJAX call is dynamically inserted by the user. The user can decide what code of Javascript to put, so he may call a AddUser() function in the web service, or do something else. Then, that piece of code is inserted dynamically and the button will add all the Javascript that the user wrote into the HTML content.
In the case the user decides to call the Jquery and specifically adds a code to call the AddUser() function in the WS, how can I do it securely? How can I assure that this AJAX request is coming from the same domain?
I understand that every HTTP Request header can be manipulated, so how can I assure that the AJAX call is coming from the same site?
I remind you, the purpose of that web service is for internal uses of the system - so I don't want that an external user will read the JS code and copy it an add users as much as he wants!
I don't want to use tokens or identification. It is a stateless request and I just want to add a user but to have control of who is making the call.
I will be happy to get any suggestion. Thank you in advance!
In my opinion you can't. You either add some kind of authentication (if you have one on the site you may use the same authentication) or render a token on the page which is sent with the AJAX request. Of course in both cases you add some form of state but in my opinion the requirement to originate the request from the same site is a requirement to track state.
I have one simple question (doubt).
Ajax is a server side technology so it hits the server asynchronously but when we use ajax toolkit's text-box validations then even if internet is disconnected , text-box gets validated how?? is it client side?
Actually, AjaxToolkit generates javascript codes in pages. all validations are done in Client side.
The AJAXToolkit is basically a helper that implements some client-side functionality for you. The user story in WebForms is all about rapid application development. The entire WebForms infrastructure is in place in order to wrap server-side + client-side functionality in a way that allows you to create web applications like you would WinForms applications. WebForms was developed by Microsoft to allow WinForms developers to use the same techniques when developing for the web.
That being said, all asp.net validators are both client-side and server-side. Doing client-side validation without server-side validation is pointless. Client-side validation (AJAX or not) is only used to give users a more responsive UI and maybe save some server round-trips for input that can be easily detected as invalid. The true validation is done server-side when the form is POSTed. If there were only client-side validation in place, a user with malicious intent could just circumvent the validation by posting the form from a tool like Fiddler. Also, what about clients which do not support JavaScript at all? (Rare as they might be these days...)
How can I capture key events in ASP using C# code?
for example, I want to press the left key and a text box will pronounce "Left Pressed".
You misunderstand how web applications and ASP.NET work. Keys are pressed by the user on the client side, in the browser that shows HTML pages. ASP.NET and the C# code that makes up the web application run on the server side. You cannot really capture key events on the server side. Even if you could, you shouldn't - every time the user would press a key, you'd have to send it over to the server side, evaluate it and then render the page again and send it back to the browser. This would generate a lot of traffic and force page reloads very frequently, making the pages very hard to use. Even AJAX calls wouldn't help much with this.
Instead, you should handle key presses on the client side, in JavaScript code that runs inside the browser and when you encounter something that the server needs to handle, you can then perform a server call.
This site (among a bunch of others) has code samples that show how to implement key detection in JavaScript:
http://www.alessandrolacava.com/using-javascript-to-detect-the-key-pressed/
Edit:
Alternatively, you can try using Silverlight, which is a programmable browser plugin similar to Flash. Silverlight hosts the .NET Framework and can be programmed using C#. Even in this case, though, you'll handle keys on the client side, not on the server.
I've been working with jQuery and *.asmx web services lately, and I'm trying to be security-conscious in doing so.
I figure it would be possible to submit an AJAX request -- even when logged-out -- to a resource that should only be accessible while logged-in.
Thus, I include special keys and hashes with each of these AJAX requests in order to validate the user's state before performing certain server-side actions.
HOWEVER
I always assumed that Postbacks were safe in that regard. That .NET would throw an error if it received a request that had been tampered with.
Is that a safe assumption? Or should I validate ALL requests, whether they're received via AJAX or a non-AJAX HTTP POST?
I suppose both are technically HTTP POSTs, but the AJAX one only submits what you explicitly pass, whereas a normal ASP.NET one includes all viewstate values. Is that correct?
You shouldn't trust anything that comes in over HTTP - it's trivial to manufacture a GET or POST request.