September, 2010

  • Jie Li's GeekWorld

    Please install updates for ASP.Net issue immediately

    • 0 Comments

    Here’s the updated security bulletin for the issue.

    http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

  • Jie Li's GeekWorld

    ASP.Net Vulnerability and SharePoint

    • 14 Comments

    UPDATE 09/28/10: Check out new security bulletin to download updates http://www.microsoft.com/technet/security/bulletin/MS10-070.mspx

    You may have already read these articles. If not, please do it right now.

    http://www.microsoft.com/technet/security/advisory/2416728.mspx

    http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

    I will not repeat the message in those posts, but you should follow the instructions to prevent potential attacks.

    So how about SharePoint Server 2007 and WSS 3.0? It’s not on SharePoint Team Blog (yet).

    You may need to follow the workaround for ASP.Net 1.0~3.5:

    • Put error.html in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\template\layouts
    • Modify web.config in each directory under %SystemDrive%\inetpub\wwwroot\wss\virtualdirectories to have a customerror section like this: <customErrors mode="On" defaultRedirect="/_layouts/error.html" />
    • IISRESET /NOFORCE

    Update: 2007/WSS3 is not vulnerable to the attack. No workaround is needed right now, but you still need to apply the fix when it come out.

    Please follow the updated SP team blog post for 2007 issue:

    http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

    How to validate? Can I type in some non-existing pages to test if web.config changes work on SharePoint?

    The answer would be no. When you try to access a non-existing page on a SharePoint site with a modified web.config you will still have 404 codes. But SharePoint has its own custom error handler to generate those 404s for non-existing pages, which will not be able to be used directly by the attack. The workaround will be able to prevent error codes from being generated by accessing certain ASP.Net resources, and it would work if you followed the steps correctly.

    Just remember, the ultimate solution is the upcoming ASP.Net fix. This workaround is just temporary, get you protection before the patch is released. Once it’s released, apply the fix and then restore your web.config to the original ones.

    Jie

  • Jie Li's GeekWorld

    IE9 + SharePoint 2010 + HTML5

    • 2 Comments

    Disclaimer: This is not a supportability claim for using IE9 on SharePoint 2010. Browser support status will be updated here: http://technet.microsoft.com/en-us/library/cc262485.aspx once the testing is done for specific release version of browsers. Using beta software will never be supported unless you have a special support agreement signed with Microsoft like the “Go-Live” license we did during SP2010 TAP program.

    Previously in What’s the Story for HTML5 with SharePoint 2010 we mentioned that HTML5 content can be loaded in to SharePoint pages and libraries. Now Internet Explorer 9 Beta has been released, can it be used to view HTML5 content on SharePoint?

    Yes – but we need to do a little bit modification. When you visit a SharePoint 2010 site with IE9, you can open developer tools by pressing F12:

    snap0007

    You can find that it is rendered in IE9 7 Compat View, with Document Mode IE8 standards. IE9 is different than Firefox/Safari/Chrome. To ensure the max compatibility, it switches modes when visiting different websites. Unless you specified HTML5 doctype in the page, it will not render <video> and <canvas> tags. So what we need to do in addition is two items:

    1. Change doctype in master page (v4.master) to <!DOCTYPE html>

    2. Remove <meta http-equiv=”X-UA-Compatible” content=”IE=8”> . This meta tag will force IE9 to act like IE8 and no HTML5 render will be available.

    After these are done your HTML5 content should be able to be rendered correctly. The supportability of these method is unknown, so you should only use it with publishing pages since you can control the whole style by yourself.

  • Jie Li's GeekWorld

    Can I use iPad/iPhone with SharePoint 2010?

    • 19 Comments

    08/26/2011 Update: Here's the official iPad support informarion from SharePoint team - http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=960

     

    A quick answer to this question is: Yes, but that depends on how you access SharePoint.

    To understand the myth, we need to go through some details…

    How to access SharePoint content from iPhone/iPad?

    Okay, we got two methods apparently.  The first one is to use a browser like Safari on the iPhone/iPad to browse the pages directly, just like how you use that on the desktop. The second one involves Apps.

    How about the browser way? Is it supported?

    Good news is, it works most of the time. Bad news is, there is something that’s not supported by Mobile Safari currently. Although we do support all mobile browsers, that’s in Mobile View of the pages. Mobile Safari can handle those pages pretty well, but not all the full version of the pages.

    What is the problem and why can’t you fix it???!!!

    The most obvious problem is that Rich Edit controls won’t work with these iOS devices (current verison: iOS 4.0). If you dig deeper into the issue, you will find that iPhone/iPad actually won’t work with any Rich Edit fields on the internet nowadays. The problem is Mobile Safari does not support enough features as Safari does. It’s a trimmed down version of Safari, one of the attribute it does not support is contentEditable. This attribute is widely used in SharePoint, in Google Docs, in TinyMCE(One of the best WYSIWYG editor)…

    So until Apple improve their Webkit code on these devices, the only way to get around of this is to add detection code to remove Rich Edit experience for iOS devices, just like to switch to the Mobile View. There’s no way for the whole internet world to “fix” what Mobile Safari is missing.

    In SharePoint, that means things involves editing in a Rich Text way will not work: Office Web Apps Edit Mode, Page Edit Mode, etc. Viewing pages and content are good.

    Why does this contentEditable matter?

    This attribute is introduced by Internet Explorer 5.5 more than 10 years ago, and is widely supported in all modern browsers like Firefox, Safari, Chrome and Opera. It is a fundamental of creating those rich edit experience within browsers instead of a separate RIA so gradually it’s also accepted in HTML5 standard.

    Further reading on HTML5 & contentEditable: http://blog.whatwg.org/the-road-to-html-5-contenteditable

    How about the Apps way?

    There’re several Apps in App Store currently for SharePoint access. Just search for SharePoint, and you can find them. The experience varies, but in general they do the job. Currently there’s no client from Microsoft does that – if you need, you may want to consider a Windows Phone device.Smile

    What’s the conclusion?

    If you need to use these iDevices’ browser with SharePoint, you need to test your usage scenario first since Mobile Safari is not in the supported browsers for full page views anyway. You are responsible for the customizations to make unsupported browsers work. Or you can wait until Apple release some fix for their iOS to reduce the problem. No idea if their new 4.2 will do something on that currently. Apps is good to check out, but may not meet all the needs depending on how you want to use it. I don’t have a recommendation here.

    Jie.

Page 1 of 1 (4 items)