SharePoint Dragons

The following article did a nice job to explain how to hide the quick launch bar in SharePoint 2010: http://www.sharepointpromag.com/article/sharepoint/ways-add-remove-quick-launch-menu-control-140338 . It’s not that different in SharePoint 2013, although the Div IDs are different. If you follow Step 3 in the article, then create a CSS file and add the following:

/* Hide quick launch bar */

#sideNavBox {

display: none;

}

/* Hide quick launch bar */

#contentBox {

margin-left:20px !important;

}

Then reference this css file in your master page, you will have accomplished the same thing in SPS 2013!

App Catalogs are special SharePoint document libraries that contain SharePoint Apps. There are special site collections containing App Catalogs, called App Catalog sites. Each SharePoint web application is associated to a single App Catalog site, and each SharePoint farm can have multiple App Catalog sites. Every App Catalog site has two App Catalogs: one document library that is intended for SharePoint Apps, the other one is intended for Office Apps. App Catalog Sites are a great thing, because they allow you to set up a Corporate Catalog for Apps that you want to make available throughout your entire organization, or throughout certain parts in your organization. So, whereas the SharePoint Store provides a public marketplace, a Corporate Catalog provides an internal App catalog for Apps that are approved for use within the organization.

The most popular reason for creating multiple Corporate Catalogs is the need to apply different security settings on a catalog. It’s quite common that some end users need to have access to a set of Apps, while others don’t. As a bonus, limiting the number of Apps seen by the end user to a useful set makes it easier for end users to choose. Huge numbers of Apps in Corporate Catalogs usually confuse end users and are counterproductive.

In SharePoint 2013, SharePoint Apps purchased from the SharePoint Store from SharePoint Online leverage the OAuth security protocol to communicate with SharePoint.

In these cases, the client application (or: the SharePoint Aps) sends requests to the resource server (SharePoint) which hosts the resources that are controlled by the end user (or resource owner) and is capable of accepting and responding to protected resource requests using access tokens. The three roles in OAuth, consisting of client, resource server, and resource owner, are also fondly known as the OAuth Love Triangle.

In addition, the OAuth infrastructure requires the presence of an authorization server, a trusted server authenticating client applications and issuing access tokens to client applications authorizing them to access end user resources. It is possible that the server also acts as the authorization server, but the authorization server as a separate entity is equally possible. A single authorization server may serve multiple application servers. The OAuth specification doesn’t address the interaction between server and authorization server, so that implementation is completely left to the discretion of the vendor implementing OAuth. For SharePoint Online, Azure Access Control Service (ACS)  is the authorization service.

As you may have noticed, OAuth recognizes client applications (in this case, SharePoint Apps) having their own identity recognized apart from user identities. This notion sets OAuth (and S2S, the default security protocol used by SharePoint Apps in on-premises installations) apart from other authorization protocols.

Doesn’t it seems like all architectural problems in the world can be solved by adding one or more abstraction layers? OAuth is another example of this provoking thought.

In spite of Apps development being the best practice for SharePoint 2013, we expect that the additional overhead of App architecture, deployment, configuration, and management will push on-premise customers to the Farm solution customization model. For Office 365 deployments, it is clear the App model is quite a natural fit and will be by far the most popular customization model. Let’s see how things turn out a year from now…

The concept of Apps somehow makes us think of Web Services for Remote Portlets (WSRP). WSRP is a specification for defining presentation-oriented web services and it has in common with Apps that both try to offer a way to reuse applications in another environment in a fluent and integrated way. In other words, they try to make possible to reuse applications without making it to obvious to the end user that it’s a 3rd party solution. Since its 2007 version, SharePoint has been able to consume WSRP services, but although being reasonably popular in the Java world, creating WSRP producers hasn’t really taken off in the .NET/ SharePoint world. If you are interested in more information about WSRP, please check out http://en.wikipedia.org/wiki/Web_Services_for_Remote_Portlets.

The SharePoint 2013 RTM is released, but we’re pretty sure it’s not completely finished. Check out the Report Server section of Site Settings in the screenshot:

Just noticed the SharePoint 2013 Design Manager: it looks interesting http://sharepointbrian.com/2012/07/intro-to-sharepoint-2013-design-manager/ , so we’re gonna take it for a test spin!

In SharePoint 2010, the default master page was called v4.master (there’s logic in this name), in SharePoint 2013 RC it was called v15.master (there’s also logic in that name, but inconsistent with the previous version), and now, in SharePoint 2013 RTM all of a sudden it became seattle.master. What is up with that? From Microsoft, you would have expected something more professional. It takes us back to the days when we did a .NET project (a normal business application) and one of the developers named a page KnockOnMyDoor.aspx. After further inspection, his method names were even weirder, non-descriptive and the only thing consistent about it was that all the weird names appealed to his weird sense of humor. Maybe tomorrow we wake up it turns out it was all a bad dream and that there is no seattle.master.