Cross-Site Collection Navigation with Content Search Webpart

1)Configure Search Service Application with sufficient  privileges (Full Control at Webapplication level) to Search crawl log account.
2)Run full crawl making sure that , there are no crawl log errors  (in crawl history in Search Service  Application).
3)Create a Search Center site collection and edit the Content Search Webpart.
4)Add Keyword property filter (Query Text) contentclass:STS_Site and Test the query.
   You may further add, filters for  Webtemplate or Url specific results.

Debugging Class Libraries with Call Stack window and Symbol store

Hey Readers!!

After a long time I thought of writing something.

Though the current versions of SP , emphasizes on using Client OM or REST API etc so that on change code compilation can be avoided.  Still in somewhere there is no option other than using the Managed Code.

In a VS solution, including bunch of projects and having complex flow to execute , seems to time sucking and that too validate just a small piece of code.

Here's the solution !! . Write a test app (may be console/web app) and add the dll reference of project needs validation.

1)In Visual Studio-->Tools--->Options-->Debugging-->Symbols-->add the path to pdb files.

2)Each time referenced Project is modified --> Copy the dlls to gac (may be using wsp builder).As when debugging starts, debugger gets the symbols from  c:\windows\assembly\gac_msil

3)If you find that you are unable to step into the referenced project , this is because , pdb files in gac_msil folder and in compiled dlls are not matching

4)When debugging starts --> Look for Call stack window while debugger step into referenced objects--> If it shows dissembly message -->right click call  stack --> get the symbols that is added in step 1 

5) If it is unable to add the symbols which means dll is not copied to gac and pdb files are not macthing in gac_msil folder

Hope this could save the time for people struggling to debug class libraries

SharePoint hosted app to enable Geolocation column

GeoLocation field is newly introduced column type in SharePoint 2013 .You will not see any field of type GeoLocation by  by default but It needs to be enabled with program. This is quite useful to
save the Geographic info in SharePoint List.

1)Create a SharePoint hosted app and open up the Start page , here before executing actual CSOM
   following  few lines , get the context of hostweb url , app Web url and loads the sp.js

<script type="text/javascript">
    var hostweburl;
 var appweburl;
var web;
var list;
var context;
    // Load the required SharePoint libraries.
    $(document).ready(function () {

        // Get the URI decoded URLs.
        hostweburl =
            decodeURIComponent(
                getQueryStringParameter("SPHostUrl")
        );
  
  appweburl =
            decodeURIComponent(
                getQueryStringParameter("SPAppWebUrl")
        );

        // The js files are in a URL in the form:
        // web_url/_layouts/15/resource_file
        var scriptbase = hostweburl + "/_layouts/15/";

        // Load the js files and continue to
        // the execOperation function.
        $.getScript(scriptbase + "SP.Runtime.js",
            function () {
                $.getScript(scriptbase + "SP.js", execOperation);
            }
        );
    });

2)Now with the help of CSOM ,create SP list with GeoLocation column added to it.

   // Function to execute basic operations.
    function execOperation() {

       
    //context = new SP.ClientContext(hostweburl);
    
 context = new SP.ClientContext(appweburl); 
 var appContextSite = new SP.AppContextSite(context, hostweburl);
   // this.web=context.get_web();
   this.web= appContextSite.get_web();   
     // Continue your program flow here.
  context.load(this.web);

var listCreationInfo = new SP.ListCreationInformation();
listCreationInfo.set_title('CustomList');
listCreationInfo.set_templateType(SP.ListTemplateType.genericList);

this.web.get_lists().add(listCreationInfo);
this.list = this.web.get_lists().getByTitle('CustomList');


var fldCollection = this.list.get_fields();
alert(fldCollection);

var geoField = context.castTo(
fldCollection.addFieldAsXml('<Field Type="Geolocation" DisplayName="GeoLocation" Name="GeoLocation" />',
true,
SP.AddFieldOptions.addToDefaultContentType),
SP.FieldGeolocation);
geoField.set_title("Geo Location");
geoField.update();
alert(geoField);

context.executeQueryAsync(
 genericSuccess,
 genericFail
);

}

function genericSuccess(sender, args) {
    alert('success');
}
    
function genericFail(sender, args) {
    alert('Request failed. ' + args.get_message() + 
        '\n' + args.get_stackTrace());
}

    // Function to retrieve a query string value.
    // For production purposes you may want to use
    // a library to handle the query string.
    function getQueryStringParameter(paramToRetrieve) {
        var params =
            document.URL.split("?")[1].split("&");
        var strParams = "";
        for (var i = 0; i < params.length; i = i + 1) {
            var singleParam = params[i].split("=");
            if (singleParam[0] == paramToRetrieve)
                return singleParam[1];
        }
    }
</script>

3)Once this app is deployed successfully then you will see , List with name Custom List with  Geolocation locumn added to it in host site

Display Templates Bit By Bit

In SharePoint 2013 and Office 365, Content search Webpart and Search result Webpart respectively ,can be use to get the aggregated Contents based on conditions
Display Templates consists of 2 Templates
1) Control template
   a)  To show multiple groups Group template can be configured.
   b)  To show contents without groups Content Template can be configured directly
2)Item Template

Above contents are based on my understanding. If you want to modify this post please write into comments

Security Trimming for Managed Navigation in SharePoint 2013

Managed Navigation is the new concept which is introduced in SP 2013. Manged terms can be used for Navigating to Pages but it has  few limitations .
one of the limitation is, there is no OOB way to apply security trimming. But Interestingly I found one :)
So , try as follows
1)In Pages Library, Edit Page property to update the Managed metadata column ( Wiki Category can be used  for the same purpose

2)Once the Page is tagged with specific Metadata , Open  up the  Hidden Taxonomy List and break the permission for this List (here you have to make sure that , the Page and Managed Term has same unique permissions)
So Navigate to siteurl/Lists/TaxonomyHiddenList/AllItems.aspx  and find  for the metadata term , for which the page was tagged for

3)Hit 'Shared With' --> 'Advanced Setting'  and provide unique permission to this term , so that this term will be visible to only particular group or user.

Data Access in SharePoint And Remote App :Inbound and Outbound scenarios

1)Data Access in SharePoint And Remote App :Inbound scenarios

Inbound data connectivity

The following connectivity options are available for inbound scenarios:

• OAuth: An open protocol that enables secure authorization in a simple and standard way.
  AppOnly Policy : enables users to approve an application to act on their behalf without sharing their user name and password.                                                                                                         
  Server Side Code :You can use OAuth with server-side code. It is a good option if you need to run a non-interactive process, or if you need to elevate privileges to other than those of the logged-on user. For information about OAuth, see Authorization and authentication for apps in SharePoint 2013.
• Cross-domain library: A client-side alternative in the form of a JavaScript file (SP.RequestExecutor.js) hosted in the SharePoint website that you can reference in your remote app as long as they are in the same internet zone. Multi-domain Interaction : The cross-domain library allows you to interact with more than one domain in your remote app page through a proxy.                                                                        
  Client Side Code : This is a good option if you prefer your app code to run in the client rather than in the server, or if there are connectivity barriers, such as firewalls, between SharePoint and your remote infrastructure. For more information, see How to: Access SharePoint 2013 data from remote apps using the cross-domain library.
  (Click following image )

2)Data Access in SharePoint And Remote App :Outbound scenarios

Outbound data connectivity

The following connectivity options are available for outbound scenarios (see Figure 2):

• Web proxy: As a developer, you can use the web proxy exposed in client APIs such as the JavaScript/.NET client object models. When you use the web proxy, you issue the initial request to SharePoint. In turn, SharePoint requests the data to the specified endpoint and forwards the response back to your page. Use the web proxy when you want the communication to occur at the server level
  Both Javascript/.Net CSOM is available.                                                                               
  Direct calls through browser are not supported.
  For more information, see How to: Query a remote service using the web proxy in SharePoint 2013.
• Remote event receivers: You can use remote event receivers to handle events that occur to an item in the app, such as a list, a list item, or a web. These events resemble those in a traditional SharePoint solution, except that they can work with the remote components of the app for SharePoint.
  Only .Net CSOM is available.    
  Client Side Technologies are not supported .                                                                 
  App can not access resource as current logged in User .
   For more information, seeHandling events in apps for SharePoint.

•  Custom proxy page for the cross-domain library: You can use the cross-domain library to access data in your remote app if you provide a custom proxy page that is hosted in the remote app infrastructure. As the developer, you are responsible for the custom proxy page implementation and must deal custom logic, such as the authentication mechanism, to the remote app. Use the cross-domain library with a custom proxy page if you want the communication to occur at the client level. 

  Can not add SharePoint Components to Remote App                                                         
  .Net CSOM is not available
  

  For more information, see How to: Create a custom proxy page for the cross-domain library in SharePoint 2013.

  (Click following image )

What is Distributed Cache Service in SharePoint 2013 ?How does it help in authentication?

One of the big changes for the authentication infrastructure is being able to use the new Distributed Cache Service.  SharePoint uses that caching service to keep track of FedAuth  cookies for users that authenticate using FBA or SAML authentication.  In SharePoint 2010 each web front end kept their own local cache of fed auth cookies, and as a result we required you to use sticky sessions with your load  balancers to ensure that once a user got

authenticated, he or she was always redirected back to the same server so the 

authentication cookie could be found.  By using the new Distributed Cache to keep track of 

these authentication cookies, we no longer require sticky sessions when you use FBA or

SAML claims in SharePoint 2013.

 A) FBA authentication

Forms-based claims authentication is an interaction between a client computer, a SharePoint server, and a membership and role provider that is available through the ASP.NET interface.

Step 1: Assuming that the client computer does not already have a claims-based security token, forms-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint web page.

Step 2: The SharePoint server responds with a forms-based login page for the user to enter credentials.

Step 3: The user on the client computer types credentials and the client computer sends them.

Step 4: The SharePoint server then validates the sent credentials with the configured membership provider.

Step 5: The SharePoint server then queries the role provider for the roles associated with the user credentials. These become the list of role claims for the user account.

Step 6: The Security Token Service on the SharePoint server then creates a claims-based security token and stores it with the Distributed Cache service on the SharePoint farm. Claims in the security token are based on the user name and the list of roles for the user account.

The SharePoint server then creates and sends a Federated Authentication, or FedAuth, cookie to the client computer. This cookie contains an encrypted key or index to the security token. If the user is authorized to access the requested web page, through analysis of the claims in the security token and the configured permissions, the SharePoint server then sends the contents of the page. For subsequent requests, the client computer uses the FedAuth cookie for authentication.

B)SAML Based (ADFS)  claims authentication

SAML-based claims authentication is an interaction between a client computer, a SharePoint server, an identity federation server (such as Active Directory Federation Services, or AD FS), and an identity provider, which contains the actual accounts, passwords, and account attributes, such as Active Directory Domain Services, or AD DS.

Please note that this process example is deliberately simplified. AD FS and SAML claims are not required if you are using an AD DS infrastructure in which the forests and domains trust each other.

Before we step through the authentication process, let’s examine the set of trust relationships that must be in place. First, the federation server, the AD FS server, must trust the identity provider for which it is issuing SAML security tokens. In this case, the trust is implicit because the AD FS server is a member of the AD DS domain, and therefore trusts the validation of security credentials by its domain controllers.

AD FS must also trust security token requests for locations on the SharePoint server.

For this trust relationship, you configure AD FS with the URLs of SharePoint web applications as relying parties. Web pages within those URLs will now be trusted for SAML security token requests.

The SharePoint server must also trust the AD FS server. The AD FS server uses a signing certificate to sign the SAML security tokens that it issues. To validate the digital signature on the security tokens issued by AD FS, you configure the SharePoint farm with the public portion of that signing certificate.

Now let’s take a look at the authentication process.

• Step 1: Assuming that the client computer does not already have a claims-based security token, SAML-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint web page.
• Step 2: The SharePoint server redirects the client computer to the AD FS server to obtain a SAML-based login page for user credentials.
• Step 3: The user types credentials and the client computer sends them to the AD FS server with a request for a SAML security token.
• Step 4: The AD FS server validates the sent credentials with the identity provider, which in this case is an AD DS domain controller.
• Step 5: The AD FS server constructs a SAML security token, signs it, and then sends it to the client computer.
• Step 6: The client computer sends a new request for the web page, this time it includes the SAML security token that it received from the AD FS server.
• Step 7: The Security Token Service on the SharePoint server then creates a claims-based security token and stores it with the Distributed Cache service on the SharePoint farm. Claims in this security token are based on the claims in the SAML security token from the AD FS server.

The SharePoint server then creates and sends a Federated Authentication, or FedAuth, cookie to the client computer. This cookie contains an encrypted key or index to the security token. If the user is authorized to access the requested web page, through analysis of the claims in the security token and the configured permissions, the SharePoint server then sends the contents of the page. For subsequent requests, the client computer uses the FedAuth cookie for authentication.

Building Custom Service Applications But When?

1)Whenever there is requirement to share the data across cross sitecollections or across farms

 or if you want to associate third party service may be for analytics or computation. building custom service application is must

2)To do so, you need to develop Webfront end server (Proxy UI for configuration), Application server (WCF end point) and SQL databases

Checkout this to get standard template to build custom service application

http://www.lifeonplanetgroove.com/introducing-the-sharepoint-service-application-starter-kit/

SharePoint Content Targeting With Audience Rules

SharePoint contents can be targeted to dynamic set of audience (SPUsers) satisfying  the Audience Rule
and matching particular user profile property or combination of multiple SharePoint groups or distribution lists

1)To do so, Under user profiles (In Central admin) --> select  Manage Audience



2)Create new audience and apply audience rules like follows and compile this audience group

Note--> You need to enable audience targeting for lists or libraries in settings page
3)Now whenever , New app part or webpart is added to the page ,(In Edit mode)In Edit toolpane, you can set custom Audience , irrespective of particular SharePoint Group

How to access REST Endpoint In SharePoint App in SharePoint Online?

1)In your SharePoint Online site (Office 365) create site collection using Developer site template
(In Ribbon-->Admin-->SharePoint)

2)In SharePoint App store , search for NAPA and Install this app.

3)Now create new Project and set the REST endpoint as shown in following images












4)In Explorer, Open the Default.aspx
and put the code as in following snippet.

<!-- Placeholder for the remote content -->

<span id="categories"></span>

<!-- Add references to the JavaScript libraries. -->
<script 
    type="text/javascript" 
    src="../_layouts/15/SP.Runtime.js">
</script>
<script 
    type="text/javascript" 
    src="../_layouts/15/SP.js">
</script>
<script type="text/javascript">
(function () {
    "use strict";

    // Prepare the request to an OData source
    // using the GET verb.
    var context = SP.ClientContext.get_current();
    var request = new SP.WebRequestInfo();
    request.set_url(
        "http://services.odata.org/Northwind/Northwind.svc/Categories"
        );
    request.set_method("GET");

    // We need the response formatted as JSON.
    request.set_headers({ "Accept": "application/json;odata=verbose" });
    var response = SP.WebProxy.invoke(context, request);

    // Let users know that there is some
    // processing going on.
    document.getElementById("categories").innerHTML =
                "<P>Loading categories...</P>";

    // Set the event handlers and invoke the request.
    context.executeQueryAsync(successHandler, errorHandler);

    // Event handler for the success event.
    // Get the totalResults node in the response.
    // Render the value in the placeholder.
    function successHandler() {

        // Check for status code == 200
        // Some other status codes, such as 302 redirect
        // do not trigger the errorHandler. 
        if (response.get_statusCode() == 200) {
            var categories;
            var output;

            // Load the OData source from the response.
            categories = JSON.parse(response.get_body());

            // Extract the CategoryName and Description
            // from each result in the response.
            // Build the output as a list.
            output = "<UL>";
            for (var i = 0; i < categories.d.results.length; i++) {
                var categoryName;
                var description;
                categoryName = categories.d.results[i].CategoryName;
                description = categories.d.results[i].Description;
                output += "<LI>" + categoryName + ":&nbsp;" +
                    description + "</LI>";
            }
            output += "</UL>";

            document.getElementById("categories").innerHTML = output;
        }
        else {
            var errordesc;

            errordesc = "<P>Status code: " +
                response.get_statusCode() + "<br/>";
            errordesc += response.get_body();
            document.getElementById("categories").innerHTML = errordesc;
        }
    }

    // Event handler for the error event.
    // Render the response body in the placeholder.
    // The body includes the error message.
    function errorHandler() {
        document.getElementById("categories").innerHTML =
            response.get_body();
    }
})();
</script>

5) to set different app permissions, click on 'Settings' in explorer and make sure  that following permissions  are not required for App to run.

Silverlight Client Object Model For Windows Phone

In SharePoint 2010,Silverlight Client Object Model was not supported for Windows Phone
But This is improved in SharePoint 2013
As Windows Phone 7.5 first creates an object of the Authenticator class or ODataAuthenticator
which were added to the SharePoint 2013 client object model for Microsoft Silverlight for Windows Phone. It then uses this object as the user’s credentials.
Read more in this msdn post

Wow!! Add SharePoint 2013 App Instantly

What an Interesting Ribbon this is !!

Now we should focus on converting the SharePoint Solutions in Apps, And that is  the SharePoint Future.