Sql Server Reporting Services Report Viewer and Script Manager – cage match!

by Jason 3. July 2009 04:27

I have an asp.net content page with a Sql server Report Viewer control on it. The master page [now] has an asp.net ScriptManager on it. This combination threw this JavaScript error: “'this._postbackSettings.async' is null or not an object”. So, I ~~Binged~~ Googled that message and found lots of hits. It appears this error occurs because the client-side code [sent via scriptmanager] is trying to determine if partial rendering will be needed and by *whom*. Since my page had no controls which would invoke and Http post/get (those were inside the IFrame containing the report viewer), the client-side code could not really deal with it. So, the solution was to disable partial rendering on the script manager on the master page (credit to this article for the idea). I took the idea in that article and made it strongly-typed (so you don’t have to do a FindControl and pass around a string control id) to make the code more durable:

Add a “ScriptManager” property on the master page to expose this control.
/// <summary>
/// Allows external access to the script manager.
/// </summary>
internal ScriptManager ScriptManager
{
get { return this.scriptManager; }
}
Add the [awesome] MasterType directive to your content page which gives strongly-typed access to your master page:
<%@ MasterType VirtualPath="~/MasterPage.Master" %>
In your content page (containing the report viewer) sink the Page_Init event as such:

protected void Page_Init(object sender, EventArgs e)
{
this.Master.ScriptManager.EnablePartialRendering = false;
}

Be the first to rate this post

Currently 0/5 Stars.
1
2
3
4
5

Tags:

Ajax

Website Authentication and Client Certificates

by Jason 26. June 2009 00:33

Security is a significant consideration for any website that exists on virtually any network (Intranet, Extranet, Internet). Security threat analysis and design is a large topic with a myriad of options, trade-offs and complexities. As with any facet of software, a balance between data sensitivity, pragmatism and scope must be made. One consideration is taking another look at Authentication.

Authentication is typically the initial point of a entry for a secured web-based system. For many systems, this step consists of a user providing a user id and password. Authentication can also follow the Two-factor security process whereby the user provides two forms of identification. This approach is often verbalized as “something you have and something you know”. User id + password would be considered one form of “what you know” identification. What about the “something you have”? (there is also a three-factor authentication concept, where the third component consisting of biometric data such as fingerprint or voice).

So, what can you have? Some organizations use physical devices to provide information for the second factor. Users enter their pin and receive a user-specific, lifetime-controlled, temporary password to use to gain authentication.

Good stuff, but for your website, this could be another thing for people to lose. Another approach for the second factor is the use of Client Certificates. Client Certificates are issued by a Certificate Authority (a trusted third party or an internal server to your company). While server certificates typically provide encryption services, client certificates are all about user authentication. With a Client Certificate, a client can assert who they are beyond user id and password.

[Assuming IIS] At the most basic level, setting up this scenario involves 2 main steps:

Install a client certificate. Client certificates can be obtained for free or for a fee, and are installed on a user’s machine into their certificate store. Arguably this is one caveat with this particular approach: machine affinity.
In IIS, go to “Directory Security” > Secure communications > Edit… and configure the site to use HTTP, and require client certificates:

Once you’ve done this, the web server and the client [browser] will have a little chat to prompt, obtain, verify and ultimately accept or reject a client certificate. Following the handshake, you can see the client certificate flowing in the Http (using Fiddler in this case) as well:

At this point, the communication is established, and the server-based code could map the user to an Active Directory account [impersonate as desired too], or map to some other form of membership store, etc.

Certainly this example could be taken much further but the salient point is that digital certificates and augment the standard username + password authentication to boost security.

Be the first to rate this post

Currently 0/5 Stars.
1
2
3
4
5

Tags:

TFS shelves and branching – Protect changing code

by Jason 26. June 2009 00:27

Even for small projects, perhaps with 1 (yes 1!) developer can benefit from using branching techniques in their Source Control system. For example, imagine you have a custom software product that is in production and is also under development for the next version. “Fine”, you say, I just work on the next version in the main codebase, what’s the big deal? Well, what if, during the development time a critical production bug fix is required? Hm…that rockin’ new feature you’re so excited to show your client is baked into the codebase? Well, you *could* shelve the code, and pull down the latest. That’s certainly one option, but still easy to make mistakes and check into the main codebase. Branching can make a lot of sense for scenarios like this and TFS makes this easy:

Within Team Explorer, right-click on your project and choose “Branch…”
When presented with the dialogue, provide a name for your new branch. Consider providing something meaningful (not just a “2” suffix ;) ). Click OK.
TFS will create a separate branch in Source Control and on your local disk drive if you choose the corresponding checkbox:
Now you can open your solution from this new branch.
1. You might also considering renaming the solution (right-click from within visual studio on the solution node and choose Rename). Rename it to the same name as your branch. This is helpful so when you have the solution open its more evident which branch you are working on, and this will show up in the “Recents” list in visual studio.
At this point, now you can conduct all the glorious coding for the next world-rocking version of your application (you know, the one that’s going to make your company bust out an IPO and make you an “insta millionaire”. Equally important, now you can conduct production fixes back in the main branch of code.
TFS makes combining branches (known as “Merging”) pretty simple as well. You can merge bi-directionally. For example, if you had to make a bug fix in production, you’d likely want to merge from the main branch back into the “Next version” branch. Of course, once you get the next version of code completed and it blows through QA squeaky clean, and into production, you’ll want to merge from the branch back into the main branch. (you may want to wait a few weeks for a production release to stabilize prior to merging back into the main branch).
To Merge, right-click on the branch you want to merge (ex. the next version branch *into* the main branch) and choose “Merge…”. The screens are intuitive, but refer to MSDN for any specifics on this. Here’s an example of the screenshots encountered when merging a production bug fix into a “future release” branch (mocked up horribly in Paint so as to not reveal real source code names):
Click next and sing the praise of merging.
At this point, the changes you merged will be pushed into the target branch, and in a checked-out state. Just check in.
1. Consider using labels as well. You may find value in applying a label to your code to designate points in your code such as before/after merges or even branches.