I'm wondering if someone can point me in the right direction. I've got an ASP.NET web application. And there's autogenerated portion of JavaScript in every page that handles postback. Sometimes that javascript is surrounded by
<[CDATA[ ... ]]>
, while on the other machine it may be enclosed in simple HTML comment like
<!-- ... -->
So, I'm searching for an answer or a clue about what may cause this difference. Any ideas?
Answer:
The cause is version of .Net framework. Was hard to find because I used installer to setup everything, from web server to framework and application sources. Not very obvious line in httpd.conf caused latest framework to be used.
Story behind: MS changed JS generation from version 2.0 sp1 to use CDATA.
Thanks for replies.
You didn't said about what do you mean by different machine. If different machine is used for web server, then it's because of .NET framework version. As I recall, prior to .NET2.0sp1 CDATA wasn't used.
My guess is that it is not the machine that matters but the user's browser that may be different. Javascript will be rendered differently for "down-level" browsers which do not support Javascript. So, the JS section will be enveloped by an HTML comment tag.
Related
Spoiled by Ruby on Rails (3), I expect all my HTML output to be automatically encoded.
I asked this question about script exploits a bit earlier and am now wondering, is there some setting, plugin or extension for ASP.NET that will automatically cause all HTML to be HtmlEncode'ed or do I have to be really careful and ensure that on my own?
Various ASP.NET controls automatically encode HTML with HtmlEncode (and a few do URL encoding with UrlEncode), but it's not universal. Here's a list of controls and what encoding (if any) they do automatically. I don't know if it's updated for .NET 4.0 or not:
Which ASP.NET Controls Automatically Encodes? (this link will ask you to save the document)
This is the blog that the above document is from:
http://blogs.msdn.com/b/sfaust/archive/2008/09/02/which-asp-net-controls-automatically-encodes.aspx
It was originally posted in Sep 2008, so it's probably current for 2.0, but not necessarily 4.0. Still a useful resource to have, though, IMO.
You should also look at the Microsoft Anti-Cross Site Scripting Library 3.1.
As pointed out by balexandre, it appears the Anit-XSS library is now part of the open source Web Protection Library:
Microsoft Web Protection Library
Also, OWASP is a good resource for security information, and they have an Enterprise Security API project (ESAPI) that is available (to varying degrees) in various programming languages. The .NET one is not complete yet, I believe.
OWASP Enterprise Security API
If you're using ASP.NET 4.0 with WebForms, then using the code nugget <%: %> will automatically HtmlEncode the output. If you're using the Razor engine, then all data is HtmlEncoded by default.
By default, ASP.Net will not accept postbacks where a Inputcontrol contains html elements. This behaviour is set at a page level by the property ValidateRequest.
If you want to accept postbacks containing html, you need to set ValidateRequest to false and HtmlEncode the userinput yourself on the server before further proceeding
We recently migrated a large ASP. website from framework 1.1 to framework 3.5 and in the process also migrated from a website to a web application.
On the surface everything seemed to work fine, but now we are discovering that none of the "pages" are doing what they used to.
The site is made up of one default.aspx page that loads all the "pages" as user controls. (I am guessing this was to achieve the same effect as having a master page before master pages were invented.)
I think we missed a trick (or twelve) during the migration. What are the big stumbling blocks that other people have experienced
Update
We managed to find the problem that was making our pages stop working, but can not figure out why: When we cleaned up the code of the main page, we added whitespace (a newline) between the open and closing tags of the control that all the other "page" user controls get loaded into. Once we removed the newline everything started working again. Can anyone explain this?
I have experienced problems during manual copying etc. that has lost the connection between the GUI controls and the event-methods in the code behind. There are differences between the different versions of ASP.NET on how the event handling is coupled, and there are even more than one way of doing it (automatic based on names or explicit in code), and this is easy to mess up when changing from one "standard" to another, which is what you do converting to a differen version of .NET. It is also an additional source of confusion for Visual Studio when you also converted from Web Site to Web Application.
I am guessing that the trick was just to do some editing in Visual Studio, and VS might have automagically re-attached event handlers etc.
One things you should know is that if your new server is 64 bit. There is a chance that the controls on the page will be loaded concurrently with the page. In a sense there will be a lot of timing issues. If you are not using 64 bit server however this is not relevant.
After reading the answer here, I understand that, if I register a user control (I guess I'm really trying to use it as a custom server control) like this:
<%# Register Assembly="MyDLL" Namespace="MyDLL" TagPrefix="myDLL" %>
Then only the codebehind is used, and the markup (.ascx) page is ignored. Why is this the case (it seems arbitrary), and how can I get around this problem without having to specify the Src="..." attribute in my Register directive? All I want to do is build a user control into a single assembly (a DLL) and hand that DLL off to another web site or web application project in such a way that the web site/app can use my user control. This should not be that hard, but apparently it is...
I am working in Visual Studio 2008, if it makes a difference.
Edit (prompted by the links in Rex's M's comments): it seems like most of the instructions for doing this kind of thing are applicable to VS2005, even the stuff on MSDN. My question is pretty much exactly stated here; is the answer provided on that thread correct
Is there any reliable, recent documentation describing this sort of thing for ASP.NET 3.5 and VS2008? I feel like using the latest versions is causing more confusion and difficulty than benefit.
The thread you linked to is indeed correct. The information which originally addressed .NET 2.0 and VS 2005 is still very applicable. .NET 3.5 does not actually change .NET 2.0, just adds extra stuff. For things that are already in .NET 2.0, they are unchanged in 3.5.
It sounds like you want the functionality of a Custom Control. In a normal user control situation, the website needs an .ascx and that cannot be placed in a DLL.
I strongly recommend to take a look at custom server controls. Since for the purpose of sharing controls over multiple projects they are better suited in my opinion than user-controls. User controls are better for internal reuse, within the same web application (i.e. on multiple pages).
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).
I'm using an older version of ASP.NET AJAX due to runtime limitations, Placing a ASP.NET Validator inside of an update panel does not work. Is there a trick to make these work, or do I need to use the ValidatorCallOut control that comes with the AJAX toolkit?
I suspect you are running the original release (RTM) of .NET 2.0.
Until early 2007 validator controls were not compatible with UpdatePanels. This was resolved with the SP1 of the .NET Framework.
The source of the problem is that UpdatePanel can detect markup changes in your page, but it has no way to track scripts correctly. Validators rely heavily on scripts. During a partial postback, the scripts are either blown away, not updated, or not run when they are meant to.
In early betas, MS had the UpdatePanel try to guess what scripts needed to be re-rendered or run. It didn't work very well, and they had to take it out.
To get around the immediate problem, Microsoft released a patched version of the validator classes in a new DLL called Validators.DLL, and gave instructions on how to tell ASP.NET to use those classes instead of the real ones. If you Google for that DLL name, you should find more information. See also This blog post.
This was a stop-gag measure and you should not use it avoid it if possible.
The real solution to the problem came shortly after, in .NET 2.0 SP1. Microsoft introduced a new mechanism to register scripts in SP1, and changed the real validator classes to use that mechanism instead of the older one.
Let me give you some details on the changes:
Traditionally, you were supposed to register scripts via Page methods such as Page.RegisterStartupScript() and Page.RegisterClientScriptBlock(). The problem is that these methods were not designed for extensibility and UpdatePanel had no way to monitor those calls.
In SP1 there is a new property object on the page called Page.ClientScripts. This object has methods to register scripts that are equivalent (and in some ways better) to the original ones. Also, UpdatePanel can monitor these calls, so that it rerenders or calls the methods when appropriate. The older RegisterStartupScript(), etc. methods have been deprecated. They still work, but not inside an UpdatePanel.
There is no reason (other than politics, I suppose) to not update your installations to .NET 2.0 SP1. Service Packs carry important fixes.
Good luck.
#Jonathan Holland: What is wrong with using Validators.dll?
Since they replace the original classes, you are quietly bypassing any bug and security fixes, enhancements, etc. that Microsoft might release in the future (or might have already released). Unless you look carefully at the web.config, you might never notice that you are skipping patches.
Of course, you have to evaluate each situation. If you are absolutely stuck using .NET 2.0 RTM, then Validators.dll is better than nothing.
#jmein
Actually the problem is that the Validator client script's don't work when placed inside of an updatePanel (UpdatePanels refresh using .innerHTML, which adds the script nodes as text nodes, not script nodes, so the browser does not run them).
The fix was a patch released by microsoft that fixes this issue. I found it with the help of Google.
http://blogs.msdn.com/mattgi/archive/2007/01/23/asp-net-ajax-validators.aspx
If for what ever reason you are unable to use the udpated version of the ASP.NET validator controls is actually very easy to validate a validation group yourself, all you need to do is call
Page_ClientValidate("validationGroupName");
Then you can use the PageRequestManager execute the validation as you need.
Definately using the updated validation controls is the way to go, but I'm quite partial to JavaScript ;)