While working on a mini-demo site today I managed to get distracted with a very minor (and irrelevant) component of the site. I felt compelled to find an elegant-ish resolution even though it served no practical purpose for the demo I was building. How often does that happen?
Image Web Part Sizing
The out-of-the-box Image Web Part is great for adding images to a site. Like all Web Parts it has some properties for changing the web parts behavior, but the problem is some of them don’t quite work as you might expect.
The width and height properties are the true target of this this post. Your initial expectation when you set them is the image displayed by the web part will resize to match the settings. This just isn’t how it works – if the image’s physical size is bigger than the Web Part then some ugly scroll-bars appear.
Figure 1: Standard ‘Image Web Part’ with the width property set.
Using a little bit of jQuery we can use these properties to apply the settings to our image as well. The following script can be added to the site using the Content Editor Web Part.
<script type="text/javascript">
$(function(){
$("img[id^='MSOImageWebPart_']").each(function(){
var width = $(this).width();
var parentDiv = $(this).parents("div.ms-WPBody");
if(width > parentDiv.width()) {
this.width = parentDiv.width();
}
});
});
</script>
Figure 2: ‘Image Web Part’ that was resized with jQuery
Note: In this example I am only manipulating the width property of the image element. This leaves the browser to calculate the height of the image to keep everything in proportion. The height could be applied as well but then the image can start to look a little distorted):
See my previous post on jQuerywhich has some useful jQuery links including Jan Tielens excellent post on deploying jQuery to a site collection via a feature. Time to get back to building the demo now the distraction has been dealt with…
In another semi-related post I was talking about anonymous access in SharePoint and a work around that can be used if you need to force authentication to work at the same time. It is as counter intuitive as it sounds…
An unexpected side affect of anonymous access can be that SharePoint web services might not work as expected. This certainly was the case in the situation I described in the other post but luckily Dave Wollerman describes a fix for this issue.
An issue I can see arising is when you start to disconnect what SharePoint is managing – configurations via central administration – versus what you are now directly responsible for managing with IIS then your maintenance headache increases. For example: In a farm you will need to make sure all front-ends are synchronised by changing the IIS settings on each server.
If for what ever reason (read disclaimer at end) you need anonymous access enabled on a SharePoint site that is using windows authentication, you will notice that even as an authorised user you are not signed in automatically. The anonymous ‘experience’ will always take precedence over the users credentials [1]. This is the way the HTTP protocol works so IIS and SharePoint are off the hook for this issue.
If you do want to be a recognised user then you will need to click on the ‘Sign In’ link at the top of the site. Depending on your browser security settings you will either be signed in automatically or prompted for credentials.
Solution
This is less of a solution and more of a work around but it will achieve the desired result. To force an auto-sign in under SharePoint you need a page that has unique permissionsto force the challenge/response for credentials. This can then be provided to the authenticated users as the ‘authenticated’ homepage url.
There are a few limitions with this method:
- Anonymous users will not be able to access this page
- To be more useful the page will probably need some redirection, i.e. To pass the user back to a global home page, and this provides its own set of challenges
- Unless the authenticated user hit this page first, i.e. They follow direct links to somewhere else in the site, they will not be signed in
Disclaimer: This was a work around to an issue I recently had to face because anonymous users and authenticated users needed to access SharePoint via the same url. There are much better ways to provide multiple authentication methods which are recommended as the preferred option.
References: [1] To be completely safe I confirmed this behavior is expected with Paul Stork at his ‘Anonymous Access: Everything you always wanted to know, but didn’t know to ask’ session while at the New Zealand SharePoint Conference.
Nick Hadlee's Blog on SharePoint and Other Occasional Rants... 