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.
Related
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.
Focusing on clients who can not afford PCI compliant servers I intend to limit credit card information to a form entry that posts to the gateway via SSL. I do not store CC info on my clients shared server. My question is about the ASP.NET web form that uses server controls and if form information is in any way run through my clients shared and potentially unsecure server just by using form elements with runat=server. In this form I am using plain html input elements to collect the CC#, CVV# and expiration date but the submit element uses runat=server as I have logic in the code behind that limits the visibility of the button if a condition is not met.
If the form on the shared server accepts card details then that server & network must be PCI compliant, the fact that the details are not stored doesn't matter. Given that its a shared server achieving compliance will be virtually impossible.
The best way to keep card data away from the shared server is to have its page host an IFrame for a page thats hosted on a dedicated, compliant server.
If you never have any postbacks that should work, but if you do have any controls that support postbacks, the cc info will possibly be included (depends upon viewstate).
It sounds like you're going to have access to the cc info, as otherwise it doesn't make sense to make the button visible or not...
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.
What is the correct way to implement server callbacks in ASP.net to update a control? I know all about AJAX and async client calls to server but what about this scenario:
You display a treeview (server control) with a list of items to the user. You have a server process running which checks a queue. When an item gets added to the queue it should update the tree control. How? Sounds easy. But seems ridiculously difficult in ASP.net.
The server cannot (generally) push content out to the client. Web browsers operate in a disconnected environment - in order to simulate "push" behavior you have to have the client periodically poll the server.
The exception to this is if you can use a technology like Silverlight or Flash, which can maintain persistent duplex connections to the server independent of the browser.
As far as I'm aware, most website that appear to dynamically "push" content out to the browser (eg. gmail, facebook chat, etc) are really polling periodically from the client.
I'm using jquery ajax to fetch data from an asp.net webservice. I'm wondering how I can secure it and have it work with jquery ajax. The service is part of my web application and to access it you have to be logged in to the application. However I'd like to further secure it. For example a consultant looking up all their customers in an autocomplete box is good, but they can instead send in some other consultant's id. What's the best way to secure this?
I've looked at this article here http://msdn.microsoft.com/en-us/library/w67h0dw7%28VS.71,classic%29.aspx . However, I don't know how to make this work with jquery ajax. Any help would be appreciated.
As far as I understand you want to make sure that you know the identity of the person using your service. If the web service is part of your application this should not be a problem by using cookies (assuming the web service is on the same domain as the site). See this e-book for some ideas.
Otherwise you could hand out temporary identifiers to the logged in members of your site which would be used in the webservice calls - this way even if the identifier is stolen, it can only be used for a limited time.
I made it more secure by using encryption. I encrypt the consultant's id when passing it via ajax, and decrypt it on the server side. Obviously I do the encryption on server side and pass it to client when rendering the page. And then ajax makes the call using that encrypted id.