Implementing Auditing Features in SharePoint 2010

Below are some of the steps provided for configuring OOB auditing feature in SharePoint 2010

First of all open the site from the browser and click on site actions menu. From the site action menu select the site settings option

 
After clicking in the site settings option SP will redirect you to the settings page.Select the site collection audit settings option from there.

Now SP will show you audit setting page where you can select various level of auditing. Select the required auditing level, set the report path list and click on OK

Now auditing feature is enabled on your site. All the viewing editing and all other tacking will be done by this feature and maintained in allocated list.

You can view audit report by clicking on the audit report option from site settings page

And here is your report. Click on the link to open it in excel

Its done..! Very simple.!

Accessing share point data on fly in share point App

In some scenarios share point app can request permission to access SharePoint data dynamically during run time. This type of app does not have to originate from SharePoint 2013. It could be an app that is launched from any website and that wants to access data on SharePoint 2013 on the fly.

To be able to get into SharePoint, this type of app must first be registered through the Seller Dashboard or the appregnew.aspx page..

 After you've registered your app, it has an app identity and is associated with a security principal, referred to as an app principal. Like users and groups, an app principal has certain permissions and rights. 

After registering the app you'll get a client id, client secret, app domain, and redirect URI associated with that particular app principal. This app information identifies that particular app principal. This app information is registered with the authorization server, Windows Azure Access Control Service (ACS).

In SharePoint 2013, the OAuth authentication and authorization flow for an app that requests permissions to access SharePoint resources on the fly involves a series of interactions between your app, SharePoint 2013, the authorization server (which is ACS), and the end user at run time.

For an app that requests permissions to access SharePoint data, you have a server that is separate from SharePoint 2013, and not part of the SharePoint farm. You, the app developer, own this server (let's call it the Development.com server). You write the code for your app and deploy the app to the Development.com server.

The Development.com server uses the SharePoint client object model (CSOM) or REST endpoints with CSOM to make calls to SharePoint 2013. The Development.com app uses OAuth to authenticate with SharePoint 2013. The ACS is where SharePoint requests an authorization code that it can send to the Development.com server. Later, the Development.com server uses the authorization code to request an access token from the ACS as part of the OAuth transaction process. The Development.com server then uses the access token to talk back to SharePoint.