I have developed a web app using ABP.IO version 5.0 (also same issue using 4.4.3).NET Core Razor pages. In the development environment everything works fine. If I deploy the application to IIS as a root-level site (access URL like https://{my site}), everything works fine. I deploy it as an application under a root-level site (access URL like https://{parent site}/{my site}) I can access the login page and hit the Identity Server, but all subsequent calls that hit the API fail. The URL for calls to the API drop the {my site} portion of the URL and I get a 404 error. The calls to the API look like https://{parent site}/api/{controller}/{method} instead of https://{parent site}/{my site}/api/{controller}/{method}.
I found a setting for the appsettings.json file (AppSelfURL) that I thought might help resolve the issue but it did nothing.
Is there a setting that forces the app to retain the complete base URL when making the calls to the API?
ABP supports sub-application deployment.
You can check this: https://github.com/abpframework/abp/pull/4101
Related
I am developing a React project for studies and would like to publish.
I tried some ways, but the site is blank, there is no data from the NEWS-API I am using.
It seems to make no mistake.
It is a front application, only react with the API.
If it helps, here's the repository link.
https://github.com/carlos-souza-dev/apinews
I visited your deployment in vercel from your github repo and noticed this issue.
You're requesting data from the API over http which is insecure, while your page hosted by vercel uses https.
Modern browsers donot allow for a page served over https to request http data.
It might just be a fixed by changing your urls to use https, or if the API didn't have https you might have to do other workarounds.(Although it's better to use an API with https support)
I noticed this by opening the console after visiting your page to see these Mixed content requests blocked error.
The reason for the blank page after loading is that the Promise to get the data from the API get rejected but never handled causing the JavaScript execution to stop
[EDIT 1]
I read through some of the code in your repository and noticed a link pointing to localhost. It looks like you tried to setup a nodejs server to proxy data through https
The API you're using does seem to have HTTPS support
Conclusion:
Try changing the links to the API to https instead of http in your react code and see if it works. If it does, there's no need for a backend server of you're own
If the API doesn't have HTTPS support however, do either one of
Migrate to a different API with HTTPS support
Try serving your static react app through the backend and pointing your react app to /path/to/api/route without an absolute url and use the proxy setting in package.json as said here for development
Point to a full path to your backend server on the internet (i.e remove localhost links)
Also note that you cannot deploy a backend to vercel but it does support serverless functions
I am developing a linkedin enabled Silverlight application. LinkedIn API calls are made through Oauth2 over REST platform. I am able to fetch authorization code,access token and make API calls while running the application as "localhost" or in local IIS. However, when I try to access the deployed application outside the environment with Public IP, I am unable to make LinkedIn API calls. While debugging with Fiddler, the trace shows that "crossdomain.xml and clientaccesspolicy.xml" not found in http://www.linkedin.com/crossdomain.xml. I am unsure why this problem occurs only when we try accessing the hosted application outside and doesn't occur while running under localhost. I have tried placing both these xml files in the root folder of IIS and also inside our application hosted folder. Looking forward for your kind suggestions/help resolving this.
Thanks,
Subbu
The Problem:
I can access my Cloud Endpoints API via the following version-specific URL:
https://[version]-dot-[myappid].appspot.com/...
but I can't access it via this main URL:
https://[myappid].appspot.com/...
the error I receive in the chrome console is this:
https://[myappid].appspot.com/_ah/api/discovery/v1/apis/userEndpoint/v1/rpc?fields=methods%2F*%2Fid&pp=0 404 (Not found)
What I've done:
First off let me say I'm very new to App Engine so apologies if this is a silly question.
I've created a Google Cloud Endpoints Backend module as part of my project in Android Studio (v0.5.6) which uses all the new gradle stuff and Objectify annotations.
I've tested my back end locally on the dev server and it all runs fine.
I then deployed it to appengine using the gradle task appengineUpdate and all went well.
I deleted previous version instances running in my app engine cloud console and made the newly deployed version (version-2) the default.
I can access and use the endpoint API fine via the version specific URL as described above but not via the main url.
I have a simple index.html file which is using the endpoint via the javascript client library to test with before building client libraries for my android app.
On both versions of the URL the index.html file renders properly, it just can't connect to the API.
If anyone knows how I can get the app to run properly on the main URL (or let me know if it's not supposed to) that would be awesome!
Many thanks!
Solution was to use appengineUpdateAll which calls both: appengineUpdate and appengineUpdateAllBackends my bad!
I have created a SPA based on the Hottowel template (angular and breeze). It works fine running it from Visual Studio, but it does not work when deploying it to our iis7. I get 404 for every request to the breeze web api controller. Loading the SPA application it self works fine.
When I try this in the browser:
http://company.com/mySPA/breeze/Repository/Metadata
I get:
<Error>
<Message>
No HTTP resource was found that matches the request URI 'http://company.com/mySPA/breeze/Repository/Metadata'.
</Message>
<MessageDetail>
No type was found that matches the controller named 'Repository'.
</MessageDetail>
What is wrong?
I found a solution.
I divided the project into two separate projects. A Breeze Web API Server and a Breeze SPA Client. I then deployed these as two separate applications, which worked.
This also makes sense in my case, because I want to be able to extend the server with functionality that the current SPA might not use, but future SPA's might.
If you encounter cross-origin issues, read this:
Using Breeze with a WebApi Service from another domain
I've got a Silverlight application which uses a built-in .ASMX WebService to access a SQL database and run some queries. Everything runs without any hitches on my Development machine.
I'm trying to deploy the application to IIS 6 and I'm having some issues.
The Silverlight application itself seems to run fine, however the Web Service does not. I get an unhandled exception error that says [Async_ExceptionOcurred] as soon as the page loads (when the page loads I'm making some Async WebService method calls).
I think this is an issue with the Web Service but I don't know what the problem is. I tried setting the WebService namespace to my URL, but that didn't work. I've tried messing with the SQL connection string in my Web Config but that also affects nothing.
One thing to note is that my IIS Virtual Directory only contains my SilverlightApp.Web folder. I know that the other folder that's part of the application contains a .ClientSettings file for the WebService, but I think this is embedded into the .xap.
Can anyone shed any light on this?
The most likely thing that's happening:
Your webservice proxy on the client is using the address of the web service it was built against: ("http://localhost...").
Things to do:
Use fiddler to confirm this is the issue. It will show you where the proxy is making the call to.
Use the overloaded constructor for the web service and specify a URI. Consider using id/deffing for debug/release. This will overwrite the settings in the client.config.
Create another endpoint in the client config for the release build (Shawn's article here) and select one or the other (again using if/defs).
There are other options as well (looking at the URI and building up the service adress)... but that's the general idea.
hth,
Erik