Dots in URL causes 404 with Web API call in .net core - asp.net-core

I have a similar requirement which is mentioned in the link Dots in URL causes 404 with ASP.NET mvc and IIS . Our requirement is, we also do have URLs with dots in the path. For example I may have a URL such as www.example.com/people/michael.phelps (This example is taken from above link)
URLs with the dot generate a 404. If we pass without the dot, then everything works. If we add the dot I get a 404 error.
The above link provide solution for earlier versions of .net where we can have webconfig files. But we are using .net core to build web API application. Dotnet core does not support webconfig files. Can someone please suggest how can we arrive at the solution by using .net core.

Late answer but we had a similar case:
We had a url looking like https:/domain.com/somepath/smoething.cd
This returned a 404 from the IIS. Adding a / at the end of the url behind the .cd fixed the issue.
Strange but notable: not all.something return a 404, .com at the end of the path for example works

Related

Bug or misconfigured? ASP.NET Core 2.1 firing 404 error on Access Denied

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);

Published Aurelia Application Virtual Directory 404 Error

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.

Web API Routing - Returning 404

I have a Web API project in MVC 4 but cannot find the URL to my web service. Rather than MVC, I am actually just using the C (controller) as I'm not returning a view and my model is located in an external project.
I'm using the default route, which is api/{controller}/{id}. The name of my controller is RESTController (I know, probably wasn't the best name) and is located at ~/Controllers/RESTController.cs
Based on naming convention, it seems that my web service should be located at localhost:port/api/REST but I'm just getting a 404 resource cannot be found error (no XML representation of the object returned or anything). Is this the expected behavior without a view?
The funny thing is that I also have a SOAP API in an external project that is actually just returning the REST API result and it works as it should. Doing unit tests on my methods passes... I just can't access it from a browser. I've tried every url imaginable.
Basically...
Would there a way to debug this? (ie. Turning on ASP.NET directory listing)
Does not having a view effect what is shown in the browser?
Shouldn't the browser return an XML file representing the object?
Am I missing something obvious?
Nevermind, I'm a moron. I found the problem... At some point I accidentally drag and dropped (drug and dropped past tense?) my Global.asax file into my Views folder... therefore my routes were not getting registered.
Working as intended now.

Sitefinity 4.4 and Extensionless URLS: Is the sf404.aspx error mapping still required

Does anyone know if you still need the sf404.aspx mapping for Sitefinity 4.4?
I'm trying to run a new test SF 4.4 project, but when I try and login the page just gives me the following:
HTTP 404 cannot find /sf404.aspx (this was mapped like that for Sitefinity 3.7)
I then changed the IIS 404 configuration from sf404 to default and now I just get HTTP/1.1 404 Object Not Found.
The project works through Cassini, but not through IIS 6.
Any ideas?
Regards,
Jacques
the sf404.aspx page is definitely only used for Sitefinity 3.x and should not be mapped in a Sitefinty 4 website.
If you are attempting to run a newer version of Sitefinity on IIS6, you need to make sure to use a wildcard mapping so that all requests go through the ASP.NET engine.
This page details everything you need to setup to run Sitefinity on IIS6: http://www.sitefinity.com/documentation/documentationarticles/installation-and-administration-guide/install-sitefinity/configuring-the-iis-to-host-sitefinity-projects
You might also find this blog post helpful: http://www.sitefinity.com/blogs/joshmorales/posts/11-02-23/installing_sitefinity_4_on_iis_6.aspx

Accessing OData service gives 404 "Resource not found error"

This could be a entirely hosting service related problem but I'll post it here in case it is a more common problem.
I'm running a OData service on my ASP.NET MVC 2 site which works fine on my laptop IIS but when I deploy it to my site at Winhost I get 404 Resource not found error when trying to access the .svc-file.
Earlier I had 2 different authentications on so I got the "System.InvalidOperationException: IIS specified authentication schemes 'Basic, Anonymous'...." error so I know that at that point the handler was trying to start the service.
After fixing that, I got the "Resource not found error".
The service is in /Services folder but it does not seem to matter. No matter where I put it it always gives me the 404 error. All the binaries from my local sites bin folder are in my remote sites bin folder.
Everything else on the site seems to be working fine.
If anyone has a solution to this, help would be much appreciated.
Finally got this figured out. Since my site is an ASP.NET MVC 2 site I need to ignore the route to the service. Otherwise ASP.NET will start looking for a controller for that URI.
So I added routes.IgnoreRoute("Services/ServiceFilename.svc/{*pathInfo}"); to my global.asax.cs and voilá problem solved.
Although I don't quite understand why the service works on my laptops IIS 7 without the ignored route.