SharePoint 2013 Peek

was  getting myself introduced to the SharePoint 2013 and from the first look.Its very  much  state of the art.
it is tune with the buzz words of cloud and Apps.

Hosting the SharePoint site in the cloud is a major improvement -- using Office 365.

So its completely off premise and gets hosted at the cloud and then accessed from off the cloud.
ACS -- identity broker sitting on the cloud--(ADFS in the cloud).Its all done for u.

HostedAppWebRoleDeploy ---
u get the app file that u can push up to the store or Corp catalog . Then SP online does is  -- it opens the project and looks for any web project -- then its uses web deploy to Windows Azure Web role.

ACS and the cloud : OAuth protocol to authenticate stuff in the cloud. -- becasuse now u can develop app in any sol -- java/PHP etc and this is the  protocl for authentication thats used.
1. Request come to SP Online. SP knows that he is requesting an APP.
2.The request is fwdded to ACS.
3.ACS generates a context token--CT and that is sent back to SP online .CT is an encrypted key and has some tokens.
4.the CT is sent back to the browser.
6.the browser now gives the CT to the remove app .

There is the CT- Refresh token -- ACS etc.
So a trust is setup between : SP online -- remote app -- ACS   .
 

HostedWInAzureApp.jpg
 
when the app is requested we are bumped off WinAzure web role.
in the previous model -- its app web.

For a o365 app -- if u hit f5-- then the sol gets deployed at o365 -- send user to ost -- to debug the same .

S2S hosting

High trust apps behind the firewall.
you have to take care of:
setting up infra
setting up trust for the same.
for every app that u install





HostedS2SappConfig.jpg
all alphabets in the GUID should be lower cased.
We use the USer profile in SP for the user whose identity we are provisioning.

ShortComings in SP2010 that were fixed :

in SandBox solution u cannot have RunwithElevatedprivilidge.Thats a limitation.
in Farm Sol -- u  garnt permissions based on user and they can have all the permission that  they require.

in Sp 2013 APP identity : Specific Apps will ask for permission to sitecoll/services that they requires.Also the access levels are aslo specified (Read/Write/Full Control).Fine grained and controlled manner. VS  tolling can do this .
App model was introduced to promote 'No touch' approach on the SP server.All code/app will be hosted outside the server .
So all the app will access from the browser on the client or on a remote web server . So none of the customization run from withing the SP server.

In Full trust sol all the code would run in the SP server box/process . Hence the code reqd to  be efcnt .Else perform issues might have cropped up. Tight coupling of the code with the server affected the upgrade of SP.
 
in SP2013 with the App model we decouple the two .


 

    ONLY CSOM supported here . So we have to use JS for the same.
    Tooling team has done some work for GUID for XML coding.
    Now the client.svc has RESTfull endpts and the data is retturned as JSON or XMl for the same

     Now u don't have to ode on sp box -- u can do so at the client level.so now u can develop on a win8 machine etc.

shows the items that can be added to the sp project.
 AppManifest is an xml file in the Content DB -- tells SP the permission that this app needs .

permission that are there for the app.
here he creates a Content Type and the perm -- read/write/full control  is required.
While deploying this app there will be  a prompt that will ask the user whether the app can get the read/write perm that was coded in the app v studio.