I've developed a web application that interacts with Sharepoint Online sites via Microsoft Graph API, and everythings are going fine.
Recently, I received a request from a client telling me that he has Sharepoint on-premise and needs to consume my web app. Actually, I didn't know how to interact with a local Sharepoint. After much research, I discovered that Microsoft has many ways to interact with on-premise Sharepoint server like CSOM, JSOM, REST API, and many more.
The problem is all of them either are injected into Sharepoint like add-ins, or attached directly to the server, so no need for authentication.
Suppose I need to consume the Rest API. my case here resides in how to obtain the access token. How my online web app would interact with the local Sharepoint Server?
Thanks in advance
Related
We're looking into writing a mobile app for our company and have a concern as to the infrastructure of how the application will connect with our data.
Our current structure for our web applications is as follows:
We have an App server which holds our .NET sites, this is externally facing (obviously)
These .NET sites interact with our API server (which is only accessible by anything on our App server) So this is only internally accessible
A mobile app will not be on our servers, but it will still need to be able to access our API's. What would be the best course of action to be able to still maintain a level of securing our data in our API's while being able to have them externally accessible by a mobile app or any other app that would need data from it?
My initial thoughts would be some sort of API key system, or perhaps API users?
Thanks!
You should encrypt your API with ssl. You can also use an API management solution. There are some open source options such as: http://wso2.com/products/api-manager/ and API Agility https://apigility.org/
I have created a provider-hosted app which was developed and tested against SharePoint Online. I now want to install this on SharePoint 2013 On Premise.
It is my intention that, despite being a provider hosted app, I wish to host the app web in IIS on the SharePoint server (single farm not a cluster). I then intend to use a local URL for my App Web URL.
I understand the process of setting up an App Catalog (On SharePoint Online) as a repository for my App which in turn will enable users to add it to a site.
I have only been able to find a guide to setup On Premise SharePoint to allow users to use the SharePoint store but I only want to set it up for third party apps.
My question is do I need to go through all the steps in this link https://technet.microsoft.com/en-gb/library/fp161236.aspx even if I don't want/require store access? I don't not want to do more than necessary and I would prefer a simple solution for my clients.
I followed this guide https://technet.microsoft.com/en-gb/library/fp161234.aspx in the hope that creating the app catalog would be sufficient but I get the error "Sorry, apps are turned off. If you know who runs the server, tell them to enable apps."
I want to know if there are any projects that use DNN 7 to interact with SharePoint 2013. The SharePoint 2013 is a Provider hosted. For the setup, DNN would be installed on the same server as the App server and SharePoint 2013 on a separate server. Normally, I would create a SharePoint app that would be installed on the App server. I want to do the same using DNN as the framework with the module as the SharePoint App. Is this possible? I would assume so since SP2013 uses client model. Should I create the SharePoint App project and included it in my DNN project?
Thanks in advance.
You can embed SharePoint apps in DotNetNuke by making use of a html module that embeds your app in an iframe element. But since your apps can be hosted on any web hosting stack, you can even probably create a DotNetNuke module that is a Sharepoint app.
You will have to register your app with Azure ACS and with the App Management Service of the SharePoint farm or SharePoint Online tenancy, to be able to establish communication.
Then, to access Sharepoint, you will have to pass an access token in each HTTP request that you can obtain from Microsoft Azure Access Control Service.
More info here.
I have hosted a SharePoint 2010 service application in a farm. I am able to access the service application using web part and timer job. Now, what I am looking for is to access the service application from a console application. This console application should be hosted out of SharePoint farm.
In other words, what is the procedure to access the SharePoint 2010 service application from an external / remote console application running in a laptop?
Thanks!!! Any help is much appreciated.
There's a good article on MSDN
http://msdn.microsoft.com/en-us/library/ee539764.aspx
I think the better answer is "It depends on your service application". Certainly some service applications like Search provide traditional web services as well as some support through the client object model. Other service apps don't have this support.
If you had a custom service application, I would think the onus would be on you to provide a web service interface into that system.
I am working within an intranet environment. We have both a production and development sharepoint server (WSS 3).
We have a 3rd party workflow product which runs on top of sharepoint. It is installed on both the production and development sharepoint servers. The workflow product can call web services I have written which are hosted on our web server.
How would I have the web services determine which sharepoint server made the call to the web service, be it the production or development server?
I would then use this information to retrieve server specific information from web.config or database etc.
Currently the site hosting web services is setup to allow anonymous access so code such as
System.Web.HttpContext.Current.User.Identity.Name;
returns an empty string. If windows authenticaion is used it returns the identity of the currently logged in user, which is no use in identifying the server the call was made from.
I need a push in the right direction to address what I believe is probably a common scenario please.
Try System.Web.HttpContext.Current.Request.UserHostName