Remote Event Receiver SP 2013

A new concept, "Remote Event Receivers" has been introduced in SP 2013.

we could create SharePoint Apps (that is a standalone module of code that is complete in itself and can be installed / uninstalled independently on a Client) that can act as event generators.
Remote event receivers are written using web services.
 
Remote Event Receivers (RER) in SharePoint Online also have before events and after events. Also called as synchronous and asynchronous events.

Before events:
Modeled as two way events because SharePoint calls into the web service to notify that an event is happening and then it will wait for a response to decide further action. So, this is a blocking event for the user.
it impact the performance by network traffic. Also, this is not guaranteed to be executed like the workflow which uses service bus architecture.
So, we need to ensure this is a light weight operation we are trying to do.

After Event:
This uses the WCF service one way method, so its guaranteed that the will execute.
Here it just notifies the remote web of the event. It doesn’t block the SharePoint processes

Note: Remote event receivers are not supported by default in SharePoint hosted app since they cannot provide the remote endpoint. This is because they are restricted to only use JavaScript.

While creating RER using visual studio, there are two methods in the WCF service:

1. ProcessEvent() 
1. that handles events that occur before an action occurs, 
2. This is a synchronous event (2-way that can handle "-ing" (current) events) that can call-back to SharePoint, for example cancelling an addition to a list
2. ProcessOneWayEvent() 
1. that handles events that occur after an action occurs, 
2. This is an asynchronous event (1-way that can handle "-ed" (past) events, fire and forget type)

 Reference:  One  Two  Three    

OAuth in sharepoint 2013

OAuth comes into picture when we want to authenticate and authorize SharePoint 2013 Apps.
It is not the protocol for authenticating users to access SharePoint.
it is the internet protocol for creating and managing app identity.
cross-platform mechanism for authentication and authorizing apps which is also one emerging internet standard.
OAuth gives the power and flexibility of having app identity in addition to the user identity. 

Few points of OAuth are:

• App should be granted permissions independently of user permission
• App can request specific permission from the user during installation
• App can be granted more permission than the user (Elevation)
• App is constrained to what it can do during and after installation

 SP 2013 apps, Office 365, SP Add-ins use OAuth for authorizing the call which is validated by SharePoint.
OAuth allows users to authorize SharePoint to provide access tokens to 3rd party apps. These 3rd party apps will then use the tokens to retrieve data from the SharePoint server for that user.
The user has granted the app access to their data without giving away their username and password
The 3rd party app does not need to store the user’s username and password
The user allows the app to act on its behalf when accessing its data

Some Important concepts of OAuth are:

1. Content Owner – User who grants permission to content in a site
2. Client App – This is the remote App (running on a Cloud or Hosted environment) that needs permission to Site Content . In our case it is SharePoint 2013 App
3. Content Server – The web server that serves the content to be accessed by App. In our case it is SharePoint 2013 Server (Cloud or On-Premise)
4. Authentication Server – Trusted server that authenticates apps and creates oAuth tokens. In our case it is Azure ACS server or oAuth compatible authentication server

Each step how OAuth works:

Step 1 –> The user accesses the SharePoint 2013 portal and SharePoint 2013 authenticates the user using Claims Authentication
Step 2 –>  SharePoint 2013 requests for the Context Token for the user, from Windows Azure ACS (Access Control Services)
Step 3 –> ACS returns Context Token
Step 4 –> SharePoint 2013 passes the Context Token to the user
Step 5 –> User accesses App using Context Token
Step 6 –> Client App pulls Refresh Token from the Context Token and requests ACS for oAuthToken
Step 7 –> ACS server returns OAuth token to the client app
Step 8 –> Client App makes CSOM/REST calls to SharePoint site by passing OAuth Token
Step 9 –> SharePoint 2013 returns site content to App based on the App Permission Manifests
Step 10 –> Client App returns the App Content to the user

 Reference :  One   Two

 

Use list defination & List Template in sharepoint

The UI can only create a list on a single server, in a single site. You can't copy this list to a different server, eg. to deploy it from your development machine to the production server.

It's also difficult to use the same list in different site collections or web applications. While you can save a list as a template, you can only use this template in the site collection it was created in.

The only way to define a list that you can easily deploy to multiple servers is by creating a list definition. Otherwise you'll have to backup and restore your entire site from one server to the other,

Deploying using a list definition can take seconds. Deploying by backup/restore can actually take day.

Main point is, There are list form customizations that can't be done without modifying the actual list definition.

Advantages of List defination

• Data is stored directly on the Web servers, so performance is typically better
• A higher level of list customization is possible through direct editing of a Schema.xml file
• Certain kinds of customization to lists require use of site and list definitions.

 List definition disadvantages

• Customization of list definition requires more effort than configuring list templates
• Editing a list definition after it has been deployed is difficult.
• Doing anything other than adding code can break existing sites
• Customizing list definitions requires access to the file system of the front-end Web server

List templates advantages

•  List templates are easy to create
• Almost anything that can be done in the user interface can be preserved in the template
• List templates can be modified without affecting existing sites that have been created from the templates
• List templates are easy to deploy

List template disadvantages

• List templates are not created in a development environment
• List templates are less efficient in large-scale environments
• If the List definition on which the list template is based does not exist on the front-end server or servers, the list template does not work

 Different between list template & list defination

 List Definition:

A list definition defines a schema for a SharePoint list. It contains information on what views are being used, which columns and content types are being used, and other metadata information.
A list definitions are created by using Visual Studio.

List Template:

A list template can either be created by end users through the SharePoint user interface using an existing list as a pattern or using an existing list instance. If based on a user-created list it is called a custom list template. A custom list template includes everything that defines the list, including list columns and site columns used by the list, content types used by the list, views defined for the list, and so on.

A list templates are created in SharePoint or SharePoint designer

Reference: One