Windows 10 20H2, VS 2019 Community
Application contains one office-js addin (typescript) + one Webapi core (c#) in a container, both components communicating with a fetch function thanks to cors.
It works properly on my local computer.
I published both components on azure, the webapi component being derived as a container instance. I checked that the correct azure addin address was entered in the webapi startup module.
Now, each individual component works properly (proof with messages from the addin and with postman for the webapi) but fetch function raises errors (message = "failed to fetch).
Could someone tell me what I did miss ?
Thanks in advance.
Closed. Finally it was about :
debugging in localhost is not enough. You have to test with Swagger. In my case I had a wrong return with a String[] and the decoration of the controller was not ok
having a plain Web api application (ie : with a wwwroot)
Related
I created a simple Blazor WASM webapp using C# .NET5. It connects to some Functions which in turn get some data from a SQL Server database.
I followed the tutorial of BlazorTrain: https://www.youtube.com/watch?v=5QctDo9MWps
Locally using Azurite to emulate the Azure stuff it all works fine.
But after deployment using GitHub Action the webapp starts but then it needs to get some data using the Functions and that fails. Running the Function in Postman results in a 503: Function host is not running.
I'm not sure what I need to configure more. I can't find the logging from Functions. I use the injected ILog, but can find the log messages in Azure Portal.
In Azure portal I see my 3 GET functions, but no option to test or see the logging.
With the help of #Aravid I found my problem.
Because I locally needed to tell my client the URL of the API I added a configuration in Client\wwwroot\appsettings.Development.json.
Of course this file doesn't get deployed.
After changing my code in Program.cs to:
var apiAddress = builder.Configuration["ApiAddress"] ?? $"{builder.HostEnvironment.BaseAddress}/api/";
builder.Services.AddHttpClient("Api",(options) => {
options.BaseAddress = new Uri(apiAddress);
});
My client works again.
I also added my SqlServer connection string in the Application Settings of my Static Web App and the functions are working as well.
I hope somebody else will benefit from this. Took me several hours to figure it out ;)
Here's what I'm doing.
Install latest Azure SDK (by the date)
Open Visual Studio 2013
Create a new Azure Mobile App project. The simple service is created with TodoItem DataObject and 2 simple controllers - TodoItemController and ValuesController
Do not change anything
Start the project
The service is started and hosted in local IISExpress on url http://localhost:50993/ (the port may vary).
The "This mobile app is up and running" web page is opened in the browser. But http 400 error is returned when I try to invoke some GET-actions: for example http://localhost:50993/api/values or http://localhost:50993/tables/TodoItem.
Any ideas? Is something wrong in my environment or is that me doing something wrong?
Thanks.
I guess you can opt out of version checking by setting a value of true for the app setting MS_SkipVersionCheck. Specify this either in your web.config or in the Application Settings section of the Azure Portal.
This generally happens when you don't add a ZUMO-API-VERSION header to the request. This is required when making requests from a REST client, but the mobile client SDKs add the header automatically.
To fix, add the header ZUMO-API-VERSION with value of 2.0.0.
To learn more, see https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-client-and-server-versioning/.
Adding
http://localhost:50993/tables/Location?ZUMO-API-VERSION=2.0.0
at the end will do the trick.
I just integrated KIIP SDK for web in my node js application and it works correctly . But the problem is it showing error on browser console on each page refresh, But this error does not affect working of this sdk, it works perfectly.
the errror message showing is,
'POST https://api.kiip.me/2.0/web/moment/?r=1426508956613 400 (Bad Request)'.
My kiip code integration is as follows,
1) Included the script file on head tag
2)Declared the app key as global variable,
kiip_app_key='app-key from kiip site';
3) And intialized the kiip instance and invoked the method.
var kiipInstance = new Kiip(kiip_app_key);
kiipInstance.setTestMode();
kiipInstance.postMoment('received offer');
Andrew from Kiip here.A few things could be causing this:
The page is running from a local file or host. Solution: run the test page on a server.
The app is not submitted for live rewards. Solution: Submit for live rewards in the Kiip dashboard.
You're passing an incorrect app key. Solution: copy the app_key for the corresponding app from the Kiip dashboard and paste it as you're global variable.
Hope this helps,
Andrew
We're moving most of our web presence to our SharePoint server in the cloud. Our current setup uses a MVC Web API for data retrieval from DB. We do not want to host the API under a separate domain and thus need to move the API under SharePoint domain as well. There is no relaxation in this requirement.
Is there a way to publish my API to SharePoint? Or is there a SharePoint specific API project template in Visual Studio? If not what are my options?
EDIT Initially I have asked that MVC API needs to be part of the SharePoint 2013. But now things are such that API can reside anywhere - inside or outside - of SharePoint, as long as it is accessible from the root domain - which so far it seems not allowed (Error message: Calls to WebProxy without an app context are not allowed."). Still trying to see if this is possible, and if yes, how?
It sounds like the proxy you want to create is already part of SharePoint JSOM. Have a look at these:
http://msdn.microsoft.com/en-us/library/office/fp179895(v=office.15).aspx
http://msdn.microsoft.com/en-us/library/office/jj245162(v=office.15).aspx
This will allow you to overcome cross origin issues. The SP.WebProxy and SP.WebRequestInfo allow you to use javascript to make a call outside of the domain where the javascript executes.
What really happens behind the scenes is that SharePoint's javascript API sends the request to your sharepoint.com tenancy server, which will then invoke the service from the SharePoint server, and return the response back to your javascript. You can implement it like so in a sharepoint-hosted app:
// this javascript executes from my-company.sharepoint.com
var responseDocument = undefined;
$('#cross').click(function () {
var ctx = SP.ClientContext.get_current();
var request = new SP.WebRequestInfo();
request.set_url('https://www.somewebapi.com/my/custom/route');
request.set_method("GET");
responseDocument = SP.WebProxy.invoke(ctx, request); // executes on sp server
ctx.executeQueryAsync(onSuccess, onError);
});
function onSuccess() {
var response = responseDocument.get_body();
alert('success ' + response);
}
function onError(err) {
alert(JSON.stringify(err));
}
...and since the remote api hosted at the other domain is called from the server, you don't have to worry about any of the cross-domain issues.
Update
To answer your update, please check the results from this link.
Have you added the remote endpoint to your AppManifest.xml?
SharePoint doesn't give you a chance to define you own routes. Thats why you can not use old fashioned SharePoint solution to publish asp.net web api. You may consider using apps for SharePoint. It's like separate App with some connections to SharePoint.
Ultimately switched to JSONP solution. Installed the WebApiContrib.Formatting.JsonP in my MVC Web API project in Visual Studio, and modified SharePoint JavaScript, that calls the API, to include ?callback=? (callback is equal to question mark). Everything stays the same. No SharePoint's proxy caller needed! No SharePoint app needed!
After upgrading to ServiceStack to 4.0.24.0, I started receiving this below error when trying to login using Google OAuth.
The same works locally on my dev machine.
Has anything changed since the 4.0.21.0?
The site is hosted on Azure as you can see from the address bar.
I've the licensed version of SS
Google OAuth Callback url is correctly registered http://somesite.azurewebsites.net/auth/GoogleOAuth
Using ServiceStack.Authentication.OAuth2 4.0.24.0
This is a pretty strange problem, but recently did some digging and here is what I found. It seems that Azure Websites doesn't like the HttpResult returning from the method Authenticate on the OAuth2Provider.
Important to note: This problem is only present when hosted on Azure Websites. ServiceStack OAuth2Providers (4.0.24 to 4.0.40) work as expected when hosted else where.
Specifically, it doesn't like the Content-Length header being set when returning a HttpResult. I'm not sure exactly why this is the case as it works locally and when deployed to my own IIS host on AWS.
I've created a repository you can deploy yourself that highlights this issue.
Azure Websites seem to be interpreting this response differently than on a standard IIS setup (eg, installed via Web Installer on a clean VM) which seems to be causing the problem.
One (not very nice) work around would be to use a GlobalResponseFilter stripping out Content-Length header of the only the GoogleOAuth2Provider response.
I've tested this out and indeed worked as expected and I was able to login using Google OAuth. Here is an example of using a GlobalResponseFilter to work around this problem.
GlobalResponseFilters.Add((req, res, dto) =>
{
if (!req.PathInfo.EndsWith("/auth/GoogleOAuth", true, CultureInfo.InvariantCulture))
{
return;
}
HttpResult httpResult = dto as HttpResult;
if (httpResult != null && httpResult.Headers.ContainsKey("Content-Length"))
{
httpResult.Headers.Remove("Content-Length");
}
});
Would be great if someone can point out why Azure websites does this.
Hope this helps.