I am not able to run any other controller in the default React app for .NET Core 6.0. Has anyone figured this out? I believe I saw a quick message on the terminal about the weatherforecast route being in the SPA proxy.
Whenever I try to go to any other route for a controller it redirects to the fallback page. I have routing setup with default settings. Just seems an odd behavior.
It's obviously a proxy issue because if I run the controller from the IIS port 7132 instead of the 44402 (spa server), I am able to retrieve the json response. There's quite a long readme file in here I can plod through but maybe someone has a better solution.
Update: I found the solution, well there were several, from setting CORS policies on the server side, etc. The easiest way was to do it "pre-flight". I found a handy file called setupProxy.js (who knew lol), where I was able to set an array of end points to proxy. And this had the /weatherforecast endpoint already specified. So now it all works! I guess I answered my own question.
const context = [
"/weatherforecast","/account"
];
Related
This isn't my area. Sorry if this is a simple question, but I've been fussing with this and looking at the express-http-proxy documentation for hours and can't come up with a solution.
I have an API I didn't build, and can't access the logs for, but it works.
https://dev.server.com/jsp/app/api/user/profile/saveLastLogin
I would like to use express-http-proxy so I can develop locally without CORS issues
app.use('/api', proxy('https://dev.server.com/jsp/app', {
https: false
}));
My problem is I don't seem to be hitting the right endpoint.
is http://localhost:8080/api/user/profile/saveLastLogin hitting
https://dev.server.com/jsp/app/api/api/user/profile/saveLastLogin OR
https://dev.server.com/jsp/app/user/profile/saveLastLogin OR
https://dev.server.com/api/user/profile/saveLastLogin OR...
I've tried all sorts of configurations. Removed and added back slashes. Looked at the documentation and gone over a bunch of the available options, and tried configuring it asynchronously.
Is there an option that will logout or in some other way let me know what endpoint my proxy is proxying to?
I am not sure if I found a bug, or if I just messed up the configuration some how.
I have an ASP.NET Core 2.1 Razor website using AzureADB2C authentication, utilizing the new 'pre-packaged' configuration utilities). When I try to access a page that my test user doesn't have access to, it returns a generic 404 page instead of going to the pre-defined AccessDenied page.
Looking at the browser URL, it is trying to go to:
https://localhost:44310/Account/AccessDenied?ReturnUrl=%2FAbout
But I think it should be:
https://localhost:44310/AzureADB2C/Account/AccessDenied?ReturnUrl=%2FAbout
(Note: if I manually put this in the browser, it works correctly)
When, you sign out, it takes you to:
https://localhost:44310/AzureADB2C/Account/SignedOut
Does anyone know if there is a configuration to control this redirect? Or is this a bug in the new 2.1 Authentication modules? (And if so, any ideas how to work around it until it is fixed?)
I reported this to MSFT as a bug and they are looking into it. But I did figure out a workaround, in case anyone else is getting this same issue.
The issue on MSFT site is: https://developercommunity.visualstudio.com/content/problem/301357/microsoftaspnetcoreauthenticationazureadb2cui-acce.html
The workaround is to use the Rewrite Middleware to redirect the call. Putting the below into the Configure method of your Startup.cs class will handle the issue.
// Workaround for AccessDenied URL error in MSFT code
RewriteOptions rewrite = new RewriteOptions().AddRedirect("^Account/AccessDenied(.*)", "AzureADB2C/Account/AccessDenied$1");
app.UseRewriter(rewrite);
I've deployed a very basic Express app through Claudia JS. It's working pretty well, but any links or redirects don't keep the API Gateway stage and so don't work.
For example I have the app deployed at http://example.execute-api.eu-west-2.amazonaws.com/production - that's the equivalent of http://localhost:3000 when running locally. If there is a link on that page along the lines of <a href="/test"> that goes to http://localhost:3000/test locally, but through the api gateway it goes to http://example.execute-api.eu-west-2.amazonaws.com/test - losing the /production part of the URL and therefore not working.
Is there a way to get Express to know that all routes need to be prefaced with /production?
The alternate solution is to use a custom domain, but that seems like a lot of hassle to solve what seems like it should be just a bit of config.
You can use something like this to build the base URL;
https://${req.apiGateway.event.headers.Host}/${req.apiGateway.event.requestContext.stage}
What are the best practices (and how to go about doing it) to support offline mode when using html5 history api for url rewrites?
For example, (hypothetically) I have a PWA SPA application at https://abc.xyz which has internationalization built in. So when I visit this link, the Vue router (which ideally could be any framework - vue, react, angular etc.) redirect me to https://abc.xyz/en.
This works perfectly when I am online (ofcourse, the webserver is also handling this redirect so that app works even if you directly visit the said link).
However, its a different story when I am offline. The service worker caches all resources correctly so when I visit the URL https://abc.xyz everything loads up as expected. However, now if I manually type the URL to https://abc.xyz/en, the app fails to load up.
Any pointers on how to achieve this?
Link to same question in github: https://github.com/vuejs-templates/pwa/issues/188
Yes, this is possible quite trivially with Service Workers. All you have to do is to configure the navigateFallback property of sw-precache properly. It has to point to the cached asset you want the service worker to fetch if it encounters a cache miss.
In the template you posted, you should be good to go if you configure your SWPrecache Webpack Plugin as follows:
new SWPrecacheWebpackPlugin({
...
navigateFallback: '/index.html'
...
})
Again, it is absolutely mandatory that the thing you put inside navigateFallback is cached by the Service Worker already, otherwise this will fail silently.
You can verify if everything was configured correctly by checking two things in your webpack generated service-worker.js:
the precacheConfig Array contains ['/index.html', ...]
in the fetch interceptor of the service worker (at the bottom of the file), the variable navigateFallback is set to the value you configured
If your final App is hosted in a subdirectory, for example when hosting it on Github pages, you also have to configure the stripPrefix and replacePrefix Options correctly.
I have a .NETCORE application being an Aurelia Framework app. I also have a .NETCORE Web API. To publish these to the server I use the CMD .net publish --framework netcoreapp1.0.
I host this site on the Default Web Site which is pointing to the Aurelia app. Inside of this site I have another application being the web api. The site and API run great. I recently tried to create a Virtual Directory to server my images. Any time I try to navigate to //mywebserver/images I get nothing but 404 errors. I can play with the permissions and have it give me a 401.2 unauthorized, but any other time I just get a 404 error.
I can create a dummy website pointing to the IIS wwwroot folder, create a virtual directory and it works like it should, so I would think it has something to do with these published apps.
For anyone who stumbles across this question. Shortly after posting I came across some information on a site. http://www.jauernig-it.de/asp-net-coreiis-serving-content-from-a-file-share/
Matthias discusses that with .netcore Virtual Directories are basically dead and you should start using app.UseFileServer in your startup.cs file.
Thank you
I seems that the '404' Http return code is the default error code in published .netCore apps (I had this return with a sql server connection problem).
I think it is not related to Aurelia. use app.UseFileServer to handle your images.