Just want to the app?
Download here: http://spsecurityscanner.codeplex.com
I recently was at a client doing an audit on the SharePoint environment, and the question of how to do continual scanning on the site for possible system/ web service / and list WebForm exposure. Mimicking and automating this behavior is no big deal, since you are essentially just dispatching requests to various static URLs. The SPList object SPFormCollections can be exposed through the SPList.Forms property, and via web services rather than using the Forms web service you are sorta relegated learning on the SPList content type methods to get access to all customized forms. The SPWeb related ones are better to keep in a mutable file that can be managed.
So da da da! Here is a simple SharePoint security scanner. The composition of the application is actually pretty straightforward; it’s only about three forms. To abstract SharePoint explicit reference requirements the OM and web service assemblies are dynamically loaded at runtime so that SharePoint references are only required when doing OM connection types. Web service ones it shouldn’t really matter.
There are about three steps to get it going:
Start the application:
Click Open Connection:
And choose the connection type, and credential specifications:
When done hit connect, and you will return to the main form. Fill in whether you want to iterate SPList objects:
You can manage the web related urls, since the SPFormCollections are automated, through the Manage Web Inclusion List:
Scan the site, then you can view the results:
So it’s not very fancy, but gets the job done. Have hacky SharePoint fun!
I was called into a client this morning to provide some development support around an application that a couple inhouse developers were working on that was attempting to make modifications to a Managed Metadata column through the use of web services. Particularly, the client was using the copy.asmx web service to attempt to set the values. They had already tried several permutations of values formats, and none of them had any effect on updating the data. Just a bunch of blank nonsense.
When attempting to work with the Managed Metadata column there are some important points to consider.
- The FieldInformation Type value will return a value of MultiChoice, but this is not the case. It’s actually Note.
- The field display name isn’t DisplayName, its DisplayName_0.
- The value to provide should be of form: [wssid];#[term name]|[term guid]
For the last point, providing a value for wssid is optional but the existence check for the particular term targeting your element is not.
Notifications are a fundamental component of a successful SharePoint continuous integration strategy approach. Maintaining continuous feedback on SharePoint products is an important counterpart of continuous integration for realizing agile SharePoint development. Without timely notifications about the status of a build, mostly broken builds, bottle necks can occur which negate the benefits of a SharePoint CI implementation.
While doing a TFS 2008 upgrade that was heavily used for SharePoint development I was recently doing for a financial institution customizing these emails came up to adapt to the organizations CI policy. Specifically, how one could include the code coverage results in the email.
Under normal circumstances TFS provides a pretty reasonable mechanism to achieve notifications for CI. Individual email alerts are structured around an XSL template found in the TFS server installation directory then under Web Services -> Services -> v1.0 -> Transforms. Adjusting the XSL will change things like the text that the user receives. It is important to note that these files, like most hived files in SharePoint, are mutable with service packs and changing them can mean that future installers will not pick up the files due to the adjusted timestamp. Thus, it is typical to make a backup of the file to restore when applying updates, then rolling in the custom changes that were made previously into the updated files.
Now for the disappointing news. After scouring the completion event schemas for builds there is no field that provides the code coverage metrics, thus it makes it really hard if one wants to include code coverage data. Without this, you can’t not only not add it to the email, but to the Build webform. As a really poor substitute you can get the code coverage data from TSWA though, and you could point the email to look at the code coverage data through that medium. I think it’s a pretty lame solution.