If you are at all into security or even if you just think technology is cool then you have to watch the latest episode of the The Code Room.  In this latest episode you will see our own Duane Laflotte, our resident top hacker as part of the team of evil doers that hack a casino in vegas.

I think it is really well done and makes some good fundamental points about security in a very entertaining way.

When I was in Cairo for the MDC a few weeks ago, I gave several talks that touched on the new membership controls in ASP.Net 2.0.  One question that came up repeatedly was how far can you stretch the provider before you have to write a custom membership provider.  The answer turns out to be not very far.  The provided membership providers are very good and very extensive, but they are also fairly rigid in their implementations. 

I think I have the 3 criteria that will force you to realize that you need to bite the bullet and write your own membership provider:

1. If you need to access your own schema that is different (in any way) from the schema provided.  Running Aspnet_regsql.exe creates a database and if you need to edit that schema then you cannot live without a custom provider except if you are adding tables for your own use, but bear in mind that the provider will just ignore your additions.


2. If you need to access data in someplace that is not supported.  Even if you want the same schema as the default providers support, you cannot use a proprietary database for that data and expect the providers to just work.  The XML provider is the most common example (though not very real world), but you could think of many scenarios including SQL 7.0 where a custom provider would be in order


3. If you need / want to insert some abstraction between the provider and the data.  Stefan Schackow of Microsoft had a great session at PDC 2005 in which he demonstrated creating a provider that allowed for the situation where your web servers were not in direct contact with the database server.  To solve that problem he wrote a provider that took a web service endpoint as its connection string.

So as you can see you are quite likely to find yourself having to write your own provider.  The good news is that it really isn’t that hard to do once you have done it once or twice

Dominick Baier of DevelopMentor, wrote on Saturday about a pretty dramatic change in the way ClickOnce security is configured by default in the RTM version of .Net 2.0. 

This is a must read if you plan to use ClickOnce and haven’t already revamped the default security settings.  If you don’t like the ramifications that not being able to disable ClickOnce brings then rather than avoiding the .Net 2.0 offering you might consider the lesser step of just removing the .application mapping from your systems.

I am hopeful that Microsoft will come up with a fix in a service pack to .Net 2.0 as they did in the original .Net 1.1 that will address this default.