How to create a udcx file for Main Data Connection in infopath?

Posted by in Infopath 2010, SharePoint Tutorials

For create a UDCX file for Main data connection, you may follow these steps as:

Open your InfoPath form and clik on “Manage Data Connection…” under the Fields in the InfoPath form, and then in new pop up window, select your Main Connection and click on “Convert to Connection file” as:

and then give your Data connection library’s path (on SharePoint site) in the textbox as:

for example: http://sharepoint_site/DataConnectionLibrary/ABC_Main_Connection.UDCX

and click on OK.

After this you can see your Main Connecion’s UDCX file is available in your site’s Data Connection Library.

SharePoint 2013 CAML Designer

Posted by in SharePoint 2013, SharePoint Tutorials

 
SharePoint 2013 CAML query builder will be a great Tool for developers, it will help to build CAML query while using the Client Side Object Model in SharePoint 2013.

SharePoint 2013 CAML query builder with advanced features 2013 can be downloaded from the below link:

How to publish SharePoint App to the Official App Store

Posted by in SharePoint 2013, SharePoint Tutorials

 
In this post, I ‘ve given you the steps to go through the process of getting your app up into the Office app store so you can start making millions.
 

 
Before you decide to submit your app to the store, you need to do a few things:

Read the app store submission guidelines at http://msdn.microsoft.com/en-us/library/jj220035.aspx. These highlight the conditions your app must meet before it will be accepted. Register for a Seller account. Check out http://msdn.microsoft.com/en-us/library/jj220034.aspx how an overview of what info you need to provide and the process of getting one. The Seller accounts can take a few days to come through, so plan ahead and be patient

Make sure you have a logo, screenshots and some descriptive text ready for the app submission. A version of your .app file that has been compiled for Release.

Decided how you are going to licence your app. The app store itself allows you to define how the app will be licensed, will it be free, will it be per purchase, per user, will there be a trial etc. Some of these decisions are not simple and require significant forethought and in some cases additional development work. For our app I decided to keep it simple and go for a free version. Microsoft published a couple of great blogs / articles helping with the licencing over at the Office apps blog.

Finally, make sure you have tested, tested and tested your app again, the submission process is very thorough and tests the functionality of your app across not only IE but all supported SharePoint 2013 browsers.

Once all of the above is ready, submitting your app is relatively simple. Navigate to the Seller Dashboard and follow the prompts to submit the app.

First choose a listing type, our app is for Project Server, so we need to choose an app for SharePoint, then click on next.
 

 
In the next screen you will be asked some information about your app like the name, version, category to list it under and some other bits and pieces. The most important part are the testing notes, these are your only real way of passing information through to the testers who are looking at your app.
 

 
As we are making the app available to everyone, there is no need to choose Trial support. Click on Next. The final bits to add before you can submit the app are screenshots and some descriptive text and links to support, EULA and Privacy policies.
 

 
Once you’€™ve added that text, click on Next and your ready to submit for validation. From experience, the validation process can take around 3-5 working days. Unfortunately at the moment there is no progress indicator of where you are in the process, with the app either being in a €˜Draft€™ or €˜Approved€™ state. Once the app has become approved, it takes a few hours for it to propagate down into the SharePoint app store and to become available for everyone to download and start using.
 

Authorization and authentication for apps in SharePoint 2013

Posted by in SharePoint Tutorials

 
Authorization and authentication for apps in SharePoint 2013
 
OAuth in SharePoint 2013
 
In SharePoint 2010, the authentication to the site is based on Classic or Claims based or Anonymous Access but in SharePoint 2013, Microsoft come up with the new mode of Authentication called as €œOAuth€.

In case of SP sites, OAuth Process Flow is as follows,

1. User Signs in SP 2013–>Security Token is generated by Identity Provider–>Token is validated & allows the user to Sign in SP sites.

OAuth is an open protocol for authorization. OAuth enables secure authorization from desktop and web applications in a simple and standard way. OAuth enables users to approve an application to act on their behalf without sharing their user name and password. For example, it enables users to share their private resources or data (contact list, documents, photos, videos and so on) that are stored on one site with another site, without users having to provide their credentials (typically user name and password).

OAuth enables users to authorize the service provider (in this case, SharePoint 2013) to provide tokens instead of credentials (for example, user name and password) to their data that is hosted by a given service provider (that is, SharePoint 2013). Each token grants access to a specific site (for example, a SharePoint document repository) for specific resources (for example, documents from a folder) and for a defined duration (for example, 30 minutes). This enables a user to grant a third-party site access to information that is stored with another service provider (in this case, SharePoint), without sharing their user name and password and without sharing all the data that they have on SharePoint.

In case of App authentication, SharePoint 2013 uses the Windows Azure Access Control Service (ACS) as the app identity provider.

2. When is using OAuth required?
 
The OAuth protocol is used to authenticate and authorize apps and services. The OAuth protocol is used:

• To authorize requests by an app for SharePoint to access SharePoint resources on behalf of a user.
• To authenticate apps in the Office Store, an app catalog, or a developer tenant.

3. Access Tokens
 
In SharePoint 2013, an OAuth STS is used only for issuing tokens (that is, server-to-server and context tokens). An OAuth STS is not used for issuing sign-in tokens, that is, they are not used as identity providers. So, you will not see an OAuth STS listed in the user sign-in page, the Authentication Provider section in Central Administration, or the people picker in SharePoint 2013.

But, SharePoint 2013 administrators can use Windows PowerShell commands to enable or disable an OAuth STS. SharePoint administrators are able to enable or disable OAuth for a given web application, similar to how they can enable or disable trusted login providers in SharePoint 2010.

SharePoint 2013 implements the OAuth protocol to allow apps that are running external to SharePoint to access protected SharePoint resources on behalf of a resource owner. In the SharePoint incoming implementation of the protocol, the OAuth roles are played by the following components:

External apps take on the role of the client.

SharePoint users take on the role of resource owner.

SharePoint 2013 takes on the role of the resource server.

ACS takes on the role of the authorization server.

4. Scope
 
An app for SharePoint requests permissions to access SharePoint resources by doing the following:

An app for SharePoint requests the permissions that it needs during installation from the user who is installing it.

The developer of an app must request, through the app manifest file, the permissions an app needs.
 
5. For an app to be granted the permissions it requested, the following conditions must be fulfilled:
 
An app must be granted permissions by the user who is installing it.

Users can grant only the permissions that they have; the user installing the app must be able to grant all permissions required by the app, or app installation fails.
 
6. An app is granted the permissions it asked for when:
 
An app is installed by a website administrator.

An app is explicitly granted permission by a tenant administrator or website administrator.

An end user gives consent.

In the app manifest file, an app requests access to specific scopes (that is, locations on SharePoint 2013). An app for SharePoint uses a permission request to specify the permissions that it needs to function correctly. The permission requests specify both the rights that an app needs and the scope at which they need the rights. In short:

An app uses permission request scopes to specify the permissions that it needs.

The requests specify both the rights and the scope that the app needs.

Scopes indicate where in the SharePoint hierarchy a permission request applies. SharePoint supports four different content scopes: site collection, website, list, and tenancy. There are also feature scopes for performing search queries, accessing taxonomy data, social features, Microsoft Business Connectivity Services (BCS) features, and Project Server 2013 features.

7. Steps in the SharePoint 2013
 
________________________________________

The OAuth authentication and authorization flow for a SharePoint 2013 cloud-hosted app is shown in Figure 1.
 

FlowDiagram

1. A user types a URL in a browser to go to a SharePoint page where a particular app is installed. In this case, the app is a Contoso.com app and the user interface element on the SharePoint page comes from the Contoso.com app.

2. SharePoint processes the page and detects that there is a component from the Contoso.com app on the page. SharePoint must get a context token that it can send to the Contoso.com app. SharePoint asks ACS to create and sign a context token that contains context information (for example, the current user, what web is being rendered on SharePoint, and other context information) and an authorization code. This context token can be used later by Contoso.com to request an access token from ACS. The Contoso.com server can use the access token to talk back to SharePoint if the Contoso.com app wants to make a web service call to SharePoint later.

3. ACS returns the signed context token to SharePoint. The signed context token is signed with an client secret that only ACS and the Contoso.com app share.

4. SharePoint renders the page, including an IFRAME pointing to the app host server—in this case, Contoso.com. When SharePoint renders the page, it also passes the context token to the IFRAME.

5. The IFRAME causes the browser to request a page from the Contoso.com server. The context token is included in the browser request that is sent to the Contoso.com server.

6. The Contoso.com server gets the context token. Contoso.com validates the signature on the context token. The token is signed with an client secret that only Contoso.com and ACS share. Contoso.com can validate that the token is really intended for it and that it is not a random request from some random server. It knows that it is part of a SharePoint request.

7. If the Contoso.com server wants to talk back to SharePoint, there is a refresh token in the context token that Contoso.com can extract, so that it can include that information in the request to ACS for an access token. Contoso.com uses the refresh token that it extracted from the context token, the context token that it got from SharePoint, and its credentials (which are its client Id value and its client secret value) to request an access token from ACS so that it can talk back to SharePoint.

8. ACS returns an access token to the Contoso.com server. Contoso.com can cache this access token. That way, the Contoso.com server doesn’t have to ask ACS for an access token every time that it talks back to SharePoint. (Or, Contoso.com can make an access token request every time and not cache the access token.) By default, access tokens are good for a few hours at a time. Each access token is specific to the user account that is specified in the original request for authorization, and grants access only to the services that are specified in that request. Your app should store the access token securely, because it is required for all access to a user’s data.

9. Contoso.com can use the access token to make a web service call or CSOM request to SharePoint, passing the OAuth access token in the HTTP Authorizationheader.

10. SharePoint returns the information that Contoso.com requested to Contoso.com. The Contoso.com app renders the IFRAME contents as a per-user request in step 1. This completes the OAuth transaction process. The user now sees the SharePoint page fully rendered.

How to switch to Design view in visual webpart using Visual Studio 2010

Posted by in SharePoint Tutorials

 
In this post, you will learn how to enable or switch to Design view in visual webpart using Visual Studio 2010
 
I was creating a visual webpart using Visual Studio 2010 for SharePoint 2010 in my sandbox server. After adding a Visual webpart to my project, it showed me the HTML Source page and there was no option for switching to Design page.

Solution:

To Enable Design View:

1. Goto Tools -> Options in Visual Studio 2010

2. Navigate to HTML Designer -> General

3. “Check” the option Enable HTML designer

4. Restart the visual studio 2010

Heard that many of our team members face the same. Hope this info would be useful.

Please find the below screen shot for reference;
 

Microsoft SharePoint Server 2013 installation scenarios are not supported

Posted by in SharePoint 2013, SharePoint Tutorials

 
The following SharePoint Server 2013 installation scenarios are not supported:
 

 

• You try to install SharePoint Server 2013 on a drive that is formatted by using Resilient File System (ReFS). In this scenario, the installation fails, and the following error message is logged in the Setup log file:

  var>datetime::[940] Catalyst file system check failed: The path root D:\ is not NTFS datetime::[940] Showing message Title: ‘Setup Warning’, Message: ‘The install location must be on a drive  formatted with NTFS. Select another drive.’ datetime::[940] Message returned: 1
• You install SharePoint Server 2013 in a workgroup.
• You install SharePoint Server 2013 on a domain controller. This scenario is supported only for development configurations and not for production configurations.
• You install SharePoint Server 2013 on Windows Web Server.
• You install SharePoint Server 2013 on a virtual machine (VM) that uses Dynamic Memory. For more information about best practice configurations for SharePoint Server 2013 and virtual machines, go to the following Microsoft TechNet website:

  Use best practice configurations for the SharePoint 2013 virtual machines and Hyper-V environment