Some links with information about creating a Google Sitemap either directly in XML or via some .NET code.
http://gerardmcgarry.com/blog/creating-a-google-sitemap-aspnet-website
http://www.codeproject.com/KB/aspnet/GoogleSiteMapProvider.aspx
Blog of developer Mikkel Ovesen My thoughts, stuff I need to remember or things I just want to share with the world
.NET Resource localization
February 20, 2010 — Mikkel OvesenResourceBlender is open source and works for .NET:
Must read and references
January 8, 2010 — Mikkel OvesenMemoryleaks with WinDbg
June 12, 2009 — Mikkel OvesenI have experienced the first major project with a memory leak problem… and how do one get started with Memory leak finding.
It is a tough task and the learning curve is quite steep.
You have to get to know the WinDbg. You can start here: http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-instructions.aspx
Tess Ferrandez has some very nice “Debugging labs”, well take a look at: http://blogs.msdn.com/tess/
If you have a problem with a memory leak, take a look at his one:
Dynamically Loading ASP.NET User Controls with jQuery
December 26, 2008 — Mikkel OvesenUPDATE (16-07-2009)
Here is a new sample website with source code, it now disposes the page object and allows for WebControl rendering.
Dynamically Loading ASP.NET User Controls with jQuery v2.zip (25.52 kb)
——————————————
This post is only relevant if you are using WebForms. If you have converted to the MVC approach, then go read about Dependency Injection or NHibernate 
If however you are using WebForms or are maintaining an application that was build with WebForms. Here is a way to partially render a usercontrol via jQuery (ajax).
Introduction
User controls are a great way to group markup and functionality, but in these AJAX times, the problem and nature of User Controls, in relation to ajax, is their fixed position in the Page Control tree.
Sam Mueller describes the issues and gives his solution to dynamically loaded user controls using jQuery.
Read it here:
http://samuelmueller.com/post/2008/12/20/Dynamically-Loading-ASPNET-User-Controls-with-jQuery.aspx
Sam Muellers raises some very interesting points, however I have two things I would like to change (URL and security).
URL
I very much like that Sam Mueller has found a solution to “directly” call a user control (view) with an URL. What I do not like is the URL to be called:
/ajax.svc/renderuc?path=/usercontrols/myusercontrol.ascx
I would like to be able to call the user control directly by this kind of URL:
/usercontrols/myusercontrol.ascx
And by using a HttpHandler this is possible. I have written an example here:
1: public class AjaxUserControlHandler : IHttpHandler
2: {
3: public void ProcessRequest(HttpContext context)
4: {
5: // Get the path to the user control
6: string path = context.Request.Url.LocalPath;
7:
8: // Intialize the pseudo page and user control
9: Page page = new Page();
10: UserControl viewControl = page.LoadControl(path) as UserControl;
11:
12: // Display error if the user control was not found
13: if (viewControl == null)
14: {
15: context.Response.StatusCode = 404;
16: context.Response.Output.WriteLine("The requested url was not found");
17: return;
18: }
19:
20: // Check existense of the AjaxEnabled attribute. Only add the AjaxEnabled attribut to
21: // user controls that is safe for direct calls
22: var type = viewControl.GetType();
23: var attributes = type.GetCustomAttributes(typeof (AjaxEnabledAttribute), true);
24: AjaxEnabledAttribute attribute = attributes.FirstOrDefault() as AjaxEnabledAttribute;
25:
26: // If the attribute was not found, display an error
27: if (attribute == null)
28: {
29: context.Response.StatusCode = 403;
30: context.Response.Output.WriteLine("Access to the resource is not allowed");
31: return;
32: }
33:
34:
35: // Check if the request is valiud with regards to the requirements of the attribute.
36: // If not, display error
37: if ((attribute.Method == RequestMethodSupport.GET && context.Request.RequestType != "GET")
38: || (attribute.Method == RequestMethodSupport.POST && context.Request.RequestType != "POST"))
39: {
40: context.Response.StatusCode = 403;
41: context.Response.Output.WriteLine(string.Format("The request method {0} is not allowed.", context.Request.RequestType));
42: return;
43: }
44:
45: // Add user control to the pages control tree
46: page.Controls.Add(viewControl);
47:
48: // Disable caching, remove this if you will allow client caching
49: context.Response.CacheControl = "No-Cache";
50:
51: // Execute and return result to Output stream
52: context.Server.Execute(page, context.Response.Output, true);
53: }
54:
55: public bool IsReusable
56: {
57: get { return true; }
58: }
59: }
To make it work, you need to add the following to httpHandlers tag in the web.config.
<add verb="*" path="*.ascx" type="[NAMESPACE].AjaxUserControlHandler, [ASSEMBLY]"/>
Security
I have implemented an AjaxEnabled attribut, so that it is not possible to directly call any of the user controls (if you know the path to them) in the solution.
The attribute is simple and looks like this:
1: public class AjaxEnabledAttribute : Attribute
2: {
3: [DefaultValue(RequestMethodSupport.All)]
4: public RequestMethodSupport Method { get; set; }
5: }
6:
7: public enum RequestMethodSupport
8: {
9: All,
10: GET,
11: POST
12: }
By doing this, the handler will only allow calls to user controls that have the [AjaxEnabled[ attribute, like this:
1: [AjaxEnabled]
2: public partial class Test : System.Web.UI.UserControl
3: {
4: ...
Conclusion
With the HttpHandler, and the attribute in place, my two concerns (url and security) are dealt with.
You are now able to call a user control directly:
/usercontrols/myusercontrol.ascx
And you are only able to call user controls that have the AjaxEnabled attribute.
Any comments and suggestions are welcome btw
Create Word Documents using .NET without Interop
December 24, 2008 — Mikkel OvesenOriginal blog post:
http://www.invoke.co.nz/products/docx.aspx
————————————————————————————–
We have decided to release another component we've been using (FREE of charge, click here to download).
This library creates Word Documents (.docx) using .NET. It is written
purely in C#, you don't need any Word viewing applications or Interop
(COM) dlls installed/registered.
It works very similar to a
Repeater control, instead of HTML markup you create a docx template
using Word 2007 (Open XML format), specify parameters/placeholders to
hold values then pass the document to the library, it will then merge
those fields.
Here's an example:
To create a Word (.docx document)
- Open up Word 2007, create a new file and type in the following (without the " "):
"Hello %NAME%"
- Save & Exit (save as hello.docx)
- Create a new VS 2008 Console Application project, add a reference to the docx library, copy paste the code into Program.cs
static void Main(string[] args)
{
File.Copy("hello.docx", "hello_ready.docx", true); // create a copy of template file for later use // DocumentDataSource holds name/value pair data
DocumentDataSource source = new DocumentDataSource();
source["NAME"] = "Joe Bloggs"; // assign a value to parameter %NAME%
DocumentRenderer.ProcessDocument("hello_ready.docx", source); // process the document
Process.Start("hello_ready.docx"); // run MS Word to see merged document
}
Result
That's an over simplified example, the library is able to do a lot more, if you'd like to download it or find out more please click here,
Prevent Cross-Site Request Forgery (CSRF) using ASP.NET MVC AntiForgeryToken helper
November 26, 2008 — Mikkel OvesenOriginal post:
——————————–
Cross-site scripting (XSS) is widely regarded as the number one security issue on the web. But since XSS gets all the limelight, few developers pay much attention to another form of attack that’s equally destructive and potentially far easier to exploit. Your application can be vulnerable to cross-site request forgery (CSRF) attacks not because you the developer did something wrong (as in, failing to encode outputs leads to XSS), but simply because of how the whole Web is designed to work. Scary!
How CSRF works
So, what’s it all about? All web application platforms are potentially vulnerable to CSRF, but in this post I’ll focus on ASP.NET MVC. Imagine you have a controller class as follows:
1: public class UserProfileController : Controller
2: {
3: public ViewResult Edit() { return View(); }
4:
5: public ViewResult SubmitUpdate()
6: {
7: // Get the user's existing profile data (implementation omitted)
8: ProfileData profile = GetLoggedInUserProfile();
9:
10: // Update the user object
11: profile.EmailAddress = Request.Form["email"];
12: profile.FavoriteHobby = Request.Form["hobby"];
13: SaveUserProfile(profile);
14:
15: TempData["message"] = "Your profile was updated.";
16: return View();
17: }
18: }
This is all very normal. First, the visitor goes to Edit(), which renders some form to let them change their user profile details. Secondly, they post that form to SubmitUpdate(), which saves the changes to their profile record in the database. There’s no XSS vulnerability here. Everything’s fine, right? We implement this sort of thing all the time…
Unfortunately, this innocent controller is an easy target for CSRF. Imagine that an attacker sets up the following HTML page and hosts it on some server of their own:
1: <body onload="document.getElementById('fm1').submit()">
2: <form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
3: <input name="email" value="hacker@somewhere.evil" />
4: <input name="hobby" value="Defacing websites" />
5: </form>
6: </body>
Next, they somehow persuade a victim to visit this page (basic social engineering, look it up). When this HTML page loads, it submits a valid form post to /UserProfile/SubmitUpdate on your server.
Assuming you’re using Windows authentication or some kind of cookie-based authentication system such as Forms Authentication, the automated form post will be processed within the victim’s established authentication context, and will successfully update the victim’s email address to something under the attacker’s control. All the attacker has to do now is use your “forgotten password” facility, and they’re taken control of the victim’s account.
Of course, instead of changing an victim’s email address, they can perform any action that the victim can perform with a single POST request. For example, they might be able to grant administrative permissions to another account, or post something defamatory to a CMS.
Ways to stop CSRF
There are two main ways to block CSRF:
- Check that incoming requests have a Referer header referencing your domain. This will stop requests unwittingly submitted from a third-party domain. However, some people disable their browser’s Referer header for privacy reasons, and attackers can sometimes spoof that header if the victim has certain versions of Adobe Flash installed. This is a weak solution.
- Put a user-specific token as a hidden field in legitimate forms, and check that the right value was submitted. If, for example, this token is the user’s password, then a third-party can’t forge a valid form post, because they don’t know each user’s password. However, don’t expose the user’s password this way: Instead, it’s better to use some random value (such as a GUID) which you’ve stored in the visitor’s Session collection or into a Cookie.
Using the AntiForgeryToken helpers
With Preview 5, Microsoft has added a set of helpers to the “futures” assembly, Microsoft.Web.Mvc.dll, that give you a means to detect and block CSRF using the “user-specific tokens” technique.
To use these helpers to protect a particular form, put an Html.AntiForgeryToken() into the form, e.g.,
1: <% using(Html.Form("UserProfile", "SubmitUpdate")) { %>
2: <%= Html.AntiForgeryToken() %>
3: <!-- rest of form goes here -->
4: <% } %>
This will output something like the following:
1: <form action="/UserProfile/SubmitUpdate" method="post">
2: <input name="__MVC_AntiForgeryToken" type="hidden" value="saTFWpkKN0BYazFtN6c4YbZAmsEwG0srqlUqqloi/fVgeV2ciIFVmelvzwRZpArs" />
3: <!-- rest of form goes here -->
4: </form>
At the same time, Html.AntiForgeryToken() will give the visitor a cookie called __MVC_AntiForgeryToken, with the same value as the random hidden value shown above.
Next, to validate an incoming form post, add the [ValidateAntiForgeryToken] filter to your target action method. For example,
1: [ValidateAntiForgeryToken]
2: public ViewResult SubmitUpdate()
3: {
4: // ... etc
5: }
This is an authorization filter that checks that:
- The incoming request has a cookie called __MVC_AntiForgeryToken
- The incoming request has a Request.Form entry called __MVC_AntiForgeryToken
- These cookie and Request.Form values match
Assuming all is well, the request goes through as normal. But if not, boom!, there’s an authorization failure with message “A required anti-forgery token was not supplied or was invalid”.
This prevents CSRF because even if a potential victim has an __MVC_AntiForgeryToken cookie, an attacker can’t find out its value, so they can’t forge a valid form post with the same value in Request.Form. But legitimate users aren’t inconvenienced at all; the mechanism is totally silent.
Using salt
Salt? What? In case you want to protect multiple forms in your application independently of each other, you can use a “salt” value when you call Html.AntiForgeryToken(), e.g.,
1: <%= Html.AntiForgeryToken("someArbitraryString") %>
… and also in [ValidateAntiForgeryToken], e.g.,
1: [ValidateAntiForgeryToken(Salt="someArbitraryString")]
2: public ViewResult SubmitUpdate()
3: {
4: // ... etc
5: }
Salt is just an arbitrary string. A different salt value means a different anti-forgery token will be generated. This means that even if an attacker manages to get hold of a valid token somehow, they can’t reuse it in other parts of the application where a different salt value is required. (If anyone can suggest other use cases for salt, please let me know.)
Limitations of the Anti-Forgery helpers
ASP.NET MVC’s anti-CSRF helpers work very nicely, but you should be aware of a few limitations:
- All legitimate visitors must accept cookies (otherwise, [ValidateAntiForgeryToken] will deny their form posts). Arguably this isn’t a limitation, because unless visitors allow cookies, you probably don’t have anything to protect anyway.
- It only works with POST requests, not GET requests. Arguably this isn’t a limitation, because under the normal HTTP conventions, you shouldn’t be using GET requests for anything other than read-only operations.
- It’s easily bypassed if you have any XSS holes on your domain. An XSS hole would allow an attacker to read a victim’s anti-forgery token value, then use it to forge valid posts. So, don’t have XSS holes!
- It relies on the potential victim’s browser implementing cross-domain boundaries solidly. Browsers are supposed to stop foreign domains from reading your app’s response text and cookies, and are supposed to stop foreign domains from writing cookies to your domain. If an attacker manages to find a way around this, they can bypass [ValidateAntiForgeryToken]. Of course that’s not supposed to be possible. For the most part, modern browsers block this line of attack.
In conclusion, ASP.NET MVC’s anti-CSRF helpers are easy to use, and work very nicely thank you!
New ASP.NET Charting Control
November 26, 2008 — Mikkel OvesenMicrosoft released a free ASP.NET charting controls.
Read more about it here:
Or take a qucik look directly on these following link:
Microsoft recently released a cool new ASP.NET server control – <asp:chart /> – that can be used for free with ASP.NET 3.5 to enable rich browser-based charting scenarios:
Packer for .NET – compress JavaScript and CSS files
November 26, 2008 — Mikkel OvesenThe title says it all. Read about it here:
http://brennan.offwhite.net/blog/2008/11/23/packer-for-net-401-released/
Or take a look at the documentation:
http://svn.offwhite.net/trac/SmallSharpTools.Packer/
Dynamic controls in ASP.NET
November 25, 2008 — Mikkel OvesenAs many articles point out it is important to load dynamic control in the Init event of the life cycle. This is important if you want to preserve the view state.
Another thing I found out… you need to instantiate the control, add it to a ControlCollection and then set the properties of the control. If you set the properties before it is added to a ControlCollection. The view state does not work.
This is wrong
BaseProductControl control = (BaseProductControl)this.Page.LoadControl(product.ViewControl);
control.ProductId = productId;
ProductViewPlaceHolder.Controls.Add(control);
This will work
BaseProductControl control = (BaseProductControl)this.Page.LoadControl(product.ViewControl);
ProductViewPlaceHolder.Controls.Add(control);
control.ProductId = productId;