I think I have a similar issue as this post-
Webactivator doesn't run on IIS 7
Swashbuckle running with katana-owin based web api is able to work with IIS Express.
assume all the urls below have an "http" prefix.
I can browse to something like localhost:8085/swagger Which redirects me correctly to localhost:8085/swagger/ui/index
But when published to IIS redirects to localhost/swagger/ui/index instead of localhost/myapp/swagger/ui/index and this results in a 404. Notice that even though an application name is specified while publishing somehow swashbuckle/swagger doesn't know and only uses the pathbase without the application name.
basically it just picks up the site root URL instead of the application URL that was used to call /swagger
Any solution to this problem?
I got the same issue. Solved this using the following code (c.RootUrl)
config.EnableSwagger(c =>
{
c.IncludeXmlComments(GetXmlCommentsPath());
c.SingleApiVersion("v1", "yourAPI");
c.RootUrl(req => req.RequestUri.GetLeftPart(UriPartial.Authority) + VirtualPathUtility.ToAbsolute("~/").TrimEnd('/'));
});
Reference : Relative path for UI request URL
Related
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 am using VS 2013 and MVC5
To host the application in IIS, i have used Properties-> Web ->Servers ->Local IIS and clicked on Create Virtual directory.
So this created a VD for "MyPortal"
But now i have a path problem.
I have an api controller in my application.
When i was using VS development server it was being accessed using the url : localhost:1553/api/menuapi and the data was getting accessed correctly.
But once it is hosted to IIS, it stopped working.
When checked, it is trying to fetch the data from url i.e :
localhost/api/menuapi and it gives a 404 error.
But actually the api is fine and the data is accessible from the url :
localhost/MyPortal/api/menuapi
Why and how is this path problem created?
The below is how i am doing the api call :
1. In javascript file :
$http.get('/api/menuapi/' + menuid).success(function (data) {});
Please suggest if any alternatives.
The problem is that your javascript will only works if the application is deployed on the top level of the webserver (/), as you are using an absolute url.
If your javascript is executed at the top level of your application, you could just change your url as relative:
$http.get('api/menuapi/' + menuid).success(function (data) {});
but if your javascript in a view, a better approach would be to retrieve the proper full url with:
#Url.Content("~/api/menuapi/")
like:
$http.get('#Url.Content("~/api/menuapi/")' + menuid).success(function (data) {});
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.
The default app url looks like http://[app prefix]-[app id].[domain name]/[site collection path]/[app path]/pages/default.aspx.
It is unconvinient because every deployment during development generates new url. And after development stage the end users need a permanent link to the application, but every bug fixes or updates that will be deployed will cause new app url generation. Is there right way to fix the app url?
You can create a URL controller:
Create a list that would contain two fields: fakeUrl, realUrl,
fakeUrl can be something like "http://staticappname.[domain name]/[site collection path]/[app path]/pages/default.aspx"
realUrl would be your http://[app prefix]-[app id].[domain name]/[site collection path]/[app path]/pages/default.aspx
Give your users fakeUrl
Create a HTTPModule that would read the list and redirect the http request to the realUrl
After you redeploy your app, just change the realUrl in the list
***I'm not if this is your case but you could change your app to be a provider-hosted. Then you would get a static Url
You can open your SharePoint hosted add-in using an alternate link like:
http://[SharePointSite]/[Add-inName]
For eg.
http://contoso.com/sharepointhostedapp/
My URLs aren't resolving correctly.
When I deploy my app name is omitted from the urls.
Its suppose to be:
http:////Content/images/ect
But it gets rendered as
http:///Content/images/ect
which obviously doesn't resolve.
My URLS looks like this:
<img src="/Content/images/Misc/Lock.png" />
If I add a ~ to the url (before content) it resolves perfectly when deployed, but breaks in my dev environment.
This being a MVC app means I also have a few ajax calls to actions (controller/action/) which also does not resolve, breaking most of the site.
I deployed under the default web site in IIS, moving it to another site is not an option.
Any advice will be greatly appreciated.
Have you tried using Url.Content?
It would be something like this (untested)
<img src="#Url.Content("~/Content/images/Misc/Lock.png")" />
This has to do with your host, if you are running this site as a sub site and not under its own IIS site, the host requires the ~. I have gotten around this by using a global javascript variable to hold the site root. I populate the variable in the main site layout like so:
var gSiteRoot = '#MvcHtmlString.Create(Url.Content("~/"))';
Then when I need to construct a url in js I use it like so:
var url = gSiteRoot + 'restofurl';