I have managed to get the sources of Finch PocketBlogger up on
SourceForge. The sources are published under the GPL, which means that you can use the product completely free, but if you make any modifications to the source, you must distribute these under the same license.
From SourceForge you can also download the latest version as an installer file. This version is number 0.91 and includes:
Support for MetaBlogAPI
A few bug fixes
For .Text we use the MetaBlog interface as much as possible, thus allowing the use of Finch for posting to weblogs.asp.net (not tested though, because I do not own a blog there for testing), to solve this problem.
http://www.sourceforge.net/projects/finchpb/
The sources
The installer
The problem
Sharepoint Portal Server and Windows Sharepoint Services are .NET based solution platforms that facilitate the inclusion of third-party components, called web parts. These web parts are .NET web controls and can be installed on the server by an administrator. Of course, these compiled components should not be entirely trusted.
By default, Microsoft places these components in a trus level called WSS_Minimal. This allows web parts to do hardly anything. File access, calling of web services, registry access are all out of bounds. Setting up the right privileges for the right components through Code Access Security is rather complex and often developers and admnistrators take the easy way out: granting Full Trust to all webparts. This is especially common when the web parts are developed in-house. Of course this ensures that the web parts can be trusted (except for vulnerabilities), but it also blocks the use of many third-party components that are available both free and commercially.
The solution
We will create two (or more) bin folders fo storing the dll's for the web parts. One folder will contain the trusted dll's from our in-house development department and trusted partners and suppliers and is called “bin_trusted“. Other parts, of unknown origin, will be placed in a second folder, plainly callec “bin“. In the CAS setup, we can configure these folders as evidence for being 'trusted' to a certain level. This way, an administrator can easily mark a dll as trusted by moving it to the correct folder.
In the web.config of your virtual server, you will find a fragment like this:
<![CDATA[...
<system.web>
<securityPolicy>
<trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_mediumtrust.config" />
<trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_minimaltrust.config" />
</securityPolicy>
...
<trust level="WSS_Minimal" originUrl="" />
</system.web>
]]>
Change this to :
<![CDATA[...
<system.web>
<securityPolicy>
<trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_mediumtrust.config" />
<trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_minimaltrust.config" />
<trustLevel name="WSS_Split" policyFile="C:\Program Files\Common Files\Microsoft Shared Debug\Web Server Extensions\60\config\wss_splittrust.config" />
</securityPolicy>
...
<trust level="WSS_Split" originUrl="" />
</system.web>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin_trusted"/>
</assemblyBinding>
</runtime>]]>
Now make a copy of wss_minimaltrust.config in the same folder and call it wss_splittrust.config.
In wss_splittrust.config, search for the following code:
<![CDATA[<CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Nothing">
<IMembershipCondition class="AllMembershipCondition" version="1"/>
]]>Immediately after the IMembershipCondition
element insert this snippet:
<![CDATA[<CodeGroup class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust">
<IMembershipCondition class="UrlMembershipCondition"
version="1"
Url="$AppDirUrl$/bin_trusted/*" />
</CodeGroup>
]]>
Make sure that the resulting XML is wellformed and that the directories bin and bin_trusted do both exist. You shouls be set to go. To test this setup, create a webpart that needs some privilege (like accessing a webservice or connecting to a database). Place the dll in the bin folder. It should now give you a "Request for the permission of type ... failed". Now move the dll from bin to bin_trusted and try again. It should work now.
PS. This procedure assumes that you have followed all other steps to install your web part on the server, like marking the part as trusted in the web.config, placing the .dwp in the wp_catalog folder, etc...
PS2: The trick we pull here with telling .NET to probe both the bin and the bin_trusted folder for loading assemblies does not work for code-behind dll's. So no user controls. Not sure why this is, but I haven't found a work-around yet.
PS3: If you really do want to know how CAS is set up and what the concepts are, read this blog.