kwanl's blog

There are times when you want your Javascript to have different behaviour depending on which mode the page is in. For example, in design mode, you may want to turn off some functionality  or create a "preview" feature where some visual cues are provided.

Here's a little Javascript function to detect whether or not the web part page is in design mode. The script checks the value of two hidden fields set by SharePoint.

function IsInDesignMode()
{
   if(document.getElementById("MSOLayout_InDesignMode").value == '1') return true;
   if(document.getElementById("MSOTlPn_SelectedWpId").value != "") return true;
   return false;
}

There are times when you want your Javascript to have different behaviour depending on which mode the page is in. For example, in design mode, you may want to turn off some functionality  or create a "preview" feature where some visual cues are provided.

Here's a little Javascript function to detect whether or not the web part page is in design mode. The script checks the value of two hidden fields set by SharePoint.

function IsInDesignMode()
{
   if(document.getElementById("MSOLayout_InDesignMode").value == '1') return true;
   if(document.getElementById("MSOTlPn_SelectedWpId").value != "") return true;
   return false;
}

On a recent project, we wanted to display content from another server in an IFrame. However, we wanted the content to seem "seamless" and not have any vertical scrollbars appear. I managed to get some Javascript to get the job done in a simple scenario but fails in the more compliated scenario we were dealing with.

The problem was that for the script to work, both servers must be in the same domain. The typical way you would do this is to have both web pages set their document.domain property to the same the parent domain. However, as I described in another post, this breaks the SharePoint dropdown menus. Our workaround was to make the height configurable, not an entirely satisfactiory solution but still not a show-stopper.

I will check if this problem has been corrected in V3.

Here's a similiar piece of work I found on another blog.
SharePoint Page Viewer: automatically adjust iFrame height

On a recent project, we wanted to display content from another server in an IFrame. However, we wanted the content to seem "seamless" and not have any vertical scrollbars appear. I managed to get some Javascript to get the job done in a simple scenario but fails in the more compliated scenario we were dealing with.

The problem was that for the script to work, both servers must be in the same domain. The typical way you would do this is to have both web pages set their document.domain property to the same the parent domain. However, as I described in another post, this breaks the SharePoint dropdown menus. Our workaround was to make the height configurable, not an entirely satisfactiory solution but still not a show-stopper.

I will check if this problem has been corrected in V3.

Here's a similiar piece of work I found on another blog.
SharePoint Page Viewer: automatically adjust iFrame height

If you have some script in your web part page that sets the document.domain to a parent domain you will find that the SharePoint menus (Modify Shared Page, web part menus)  inexplicably stop working.

I thought you may be able to get it to work by resetting the document.domain to the original value but this is not allowed. Although, doing this anyways gets the menus to work again but I noticed other scripts stopped working.

If you have some script in your web part page that sets the document.domain to a parent domain you will find that the SharePoint menus (Modify Shared Page, web part menus)  inexplicably stop working.

I thought you may be able to get it to work by resetting the document.domain to the original value but this is not allowed. Although, doing this anyways gets the menus to work again but I noticed other scripts stopped working.

I've been doing web development on ASP.Net for some time now (3 years) and have only really recently run into this issue of a "double-hop". A double-hop occurs when you are using Windows Integrated Authentication and make a call that needs credentials on another server.

The first hop is between the client and the first server which is most likely IIS. If you have a web application (or web part) on that first IIS server that needs to call web service on another server that needs credentials, unless you configure kerberos for constrained delegation, it will fail.

The problem is that your credentials can't be passed on the the second server because with Windows Authentication your password is never sent to the first server (only a hash of it is).

I ran into this problem while working on a Reporting Services 2005 (SSRS) web part which calls the SSRS web services. There are several solutions I've read about:

1. Use basic authentication (with SSL of course)
2. Use kerberos with constrained configuration (haven't had success with this)
3. Get rid of the double hop by having the client connect to the second server directly using client-side code (JavaScript, HTML, etc).

This issue has been tricky to deal with because we originally didn't plan for it. The current solution is to do #3 which means quite a bit more JavaScript than we were expecting.

Related articles/posts:
Bryant Like's Blog: Web Parts and Web Services
Kerberos Constrained Delegation

I've been doing web development on ASP.Net for some time now (3 years) and have only really recently run into this issue of a "double-hop". A double-hop occurs when you are using Windows Integrated Authentication and make a call that needs credentials on another server.

The first hop is between the client and the first server which is most likely IIS. If you have a web application (or web part) on that first IIS server that needs to call web service on another server that needs credentials, unless you configure kerberos for constrained delegation, it will fail.

The problem is that your credentials can't be passed on the the second server because with Windows Authentication your password is never sent to the first server (only a hash of it is).

I ran into this problem while working on a Reporting Services 2005 (SSRS) web part which calls the SSRS web services. There are several solutions I've read about:

1. Use basic authentication (with SSL of course)
2. Use kerberos with constrained configuration (haven't had success with this)
3. Get rid of the double hop by having the client connect to the second server directly using client-side code (JavaScript, HTML, etc).

This issue has been tricky to deal with because we originally didn't plan for it. The current solution is to do #3 which means quite a bit more JavaScript than we were expecting.

Related articles/posts:
Bryant Like's Blog: Web Parts and Web Services
Kerberos Constrained Delegation

Recently, I have been working on a SharePoint-based web app that uses some Ajax to reduce the number of postbacks. Because it might be a long time before the user triggers another postback the page's security validation can potentially timeout; giving the user a frightening error page.

As one possible solution, I whipped together a little web part (really the Content Editor + some Javascript) to obtain a new form digest value and shim it into the current page.

While this works fairly well there is room for improvement.

First, it makes a request to the current page which can cause problems or at the very least it's a waste of bandwidth. A possible fix for this would be to create a very small stub page to call instead for updating the security validation.

Second, you must remember the purpose of the security validation. It's for security! You shouldn't be infinitely extending the security validation of the page without good reason. So it is best to only extend it based on some user action.

The example is contained in teh attached dwp (remove the .txt from the filename).

Warning: Use the FormDigest Extender at your own risk.

Recently, I have been working on a SharePoint-based web app that uses some Ajax to reduce the number of postbacks. Because it might be a long time before the user triggers another postback the page's security validation can potentially timeout; giving the user a frightening error page.

As one possible solution, I whipped together a little web part (really the Content Editor + some Javascript) to obtain a new form digest value and shim it into the current page.

While this works fairly well there is room for improvement.

First, it makes a request to the current page which can cause problems or at the very least it's a waste of bandwidth. A possible fix for this would be to create a very small stub page to call instead for updating the security validation.

Second, you must remember the purpose of the security validation. It's for security! You shouldn't be infinitely extending the security validation of the page without good reason. So it is best to only extend it based on some user action.

The example is contained in teh attached dwp (remove the .txt from the filename).

Warning: Use the FormDigest Extender at your own risk.