Hi I need to update the maxurllength of asp.net core service that is running on a service fabric cluster using kestral server.
Looking at other solutions people have recomended making changes to registry and web.config but in case of Kestral server running asp.net core on service fabric we dont have any web.config file.
Kestral server limits does not expose a way of doing this either. Is it possible to do so in ASP.net core?
Update:
I was using service fabric reverse proxy to access the service and a sample problematic URL is :
http://localhost:19081/{appname}/{servicename}/test-backend/v1.0/mode/1/context/5e2550ec-539a-4ea0-81b5-f783ce3f7c48/file/60917927-8a7d-4702-93e4-e2a5ea337937/version/2d826211703581a186b3d5d840e78117903189a5/openfile/W3sia2V5IjoiNjA5MTc5MjctOGE3ZC00NzAyLTkzZTQtZTJhNWVhMzM3OTM3OjJkODI2MjExNzAzNTgxYTE4NmIzZDVkODQwZTc4MTE3OTAzMTg5YTU6MCIsImNvbnRleHRJZCI6IjVlMjU1MGVjLTUzOWEtNGVhMC04MWI1LWY3ODNjZTNmN2M0OCIsImlNb2RlbElkIjoiNjA5MTc5MjctOGE3ZC00NzAyLTkzZTQtZTJhNWVhMzM3OTM3IiwiY2hhbmdlU2V0SWQiOiIyZDgyNjIxMTcwMzU4MWExODZiM2Q1ZDg0MGU3ODExNzkwMzE4OWE1Iiwib3Blbk1vZGUiOjEsIl9fbmFtZV9fIjoiSU1vZGVsVGlsZVJwY0ludGVyZmFjZV9JTW9kZWxUb2tlbiIsIl9fdW5yZWdpc3RlcmVkX18iOmZhbHNlfSwiMHgyWdpc3RlcmVkX18iOmZhbHNlfSwiMHgy
The last URL segment which is some encoded string is the issue.
For ASP.NET Core 1.1 KestrelServerLimits.MaxRequestLineSize should be what you are looking for.
For ASP.NET Core 2.1 KestrelServerLimits.MaxRequestLineSize should be what you are looking for.
The default on both is 8Kb, so that should be much bigger than the default 2083 Url length provided by chrome and other browsers.
If you are exposing your APIs using the Service Fabric Reverse Proxy, the problem should be the Reverse Proxy and not Kestrel.
Service Fabric Reverse Proxy uses the windows HTTP.sys driver to expose the http endpoints, by default this is limited to 260 chars per segment (values between each slash '/'), if this is the case, you should configure your machine with other values instead, in this case, you should set the value for UrlSegmentMaxLength
To do that you have to create a DWORD called UrlSegmentMaxLength under the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
and set it to a number between 0 and 32,766.
I think if you provide the real problem, we could help with a better solution.
Just one side note: .NET Core apps can be hosted with IIS as well. In that case a Reverse Proxy talks to Kerstel. Also during "dotnet publish" a web.config created for this case to make IIS work with .NET Core.
So in this scenario it means you have to set up these hosting level changes in both places. I had a lot of problem with the configuration of IIS in a .NET Core project unit found this post.
Related
How does one share session in ASP.NET Core 3 between 2 servers (load balanced)?
And can session be shared between several web services/APIs and the main ASP.NET MVC app?
I am very new to .NET Core 3, I was used to working with session state in ASP.NET Framework MVC (where it was as simple as using the same machine key in the IIS configuration of the site) but I've learned that everything changed for .NET Core 3, in addition a lot of documentation is extremely outdated/obsolete as new versions have rolled out, .NET core 1 has nothing to do with later versions and 2 with 3, and also it requires many NuGet packages which may or may not work anymore.
Currently I have successfully implemented SQL session store with .NET Core 3 but the option of machine key no longer shows up in the IIS and I really don't know how to configure them in the appsettings.json file (if still used at all).
Our setup is 2 servers which must both share the session info, with an F5 load balancer, our old apps which use .NET Framework MVC are configured like this, and I need help with achieving the same result but with .NET Core 3.
I read through https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/web-farm?view=aspnetcore-3.1 but it doesn't really explain how to actually do anything
Also this https://learn.microsoft.com/en-us/aspnet/core/performance/caching/distributed?view=aspnetcore-3.1 helped configure the SQL session storage but not how to share between the 2 servers
As well as http://www.intstrings.com/ramivemula/articles/jumpstart-44-sql-server-based-session-state-in-asp-net-core-mvc-application/
Have you configured DataProtection? I haven't worked with this in a while, but from memory this was the essential piece for distributed session storage to work in .NET Core
Here's some additional reading about both sessions and DataProtection in .NET Core with bonus mentions for MachineKey - https://andrewlock.net/an-introduction-to-the-data-protection-system-in-asp-net-core/
Your user's session authentication key is stored in a cookie within their web browser. No matter which server the user connects to, they will pass their cookie to that server and the server will authenticate their session via SQL using the authentication key.
I think this can help you:
I got it from here:
https://learn.microsoft.com/en-us/aspnet/core/performance/caching/distributed?view=aspnetcore-3.1#distributed-sql-server-cache
As detailed here: https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.httprequest?view=aspnetcore-3.0, ASP.NET Core's HttpRequest class includes both Path and PathBase properties.
What's the difference between these two properties? What's each one used for? What's the meaning of PathBase? What's the significance of having both a Path and a PathBase?
I can't find any documentation detailing why it is as it is - any ideas?
In ASP.NET core there is this concept known as the path base. The basic idea is quite easy to understand: the path base is considered to be a fixed prefix for the path of all the incoming requests to your web application. By default the path base is considered to be the empty string.
This means that, by default, when a request enters your application, all the path portion of the request's URL will be mapped to the Path property of the HttpRequest object and the PathBase property will be set to string.empty.
As an example consider an asp.net core application running in your local machine and listening to port 3000. Suppose that you are running the application by using the raw kestrel web server (so there is no reverse proxy involved, requests arrive directly to kestrel).
When you request the URL http://localhost:3000/foo/bar then the HttpRequest object will have the following properties:
HttpRequest.Path will be set to /foo/bar
HttpRequest.PathBase will be set to string.empty
You will get the same situation when you decide to host your application on Azure, by using a windows app service.
In this hosting scenario the default for an ASP.NET core web application is being executed inside the same process as the IIS worker process. This basically means that there is only one process involved; again there is no reverse proxy and the kestrel web server is not used at all: the request is handled by IIS directly (you can find some details here if you are interested).
In that case the public URL for your application will be something like https://my-application.azurewebsites.net. When you browse to the URL https://my-application.azurewebsites.net/foo/bar, the situation for the incoming http request will be the following:
HttpRequest.Path will be set to /foo/bar
HttpRequest.PathBase will be set to string.empty
Again, as before, the path base is the empty string.
There are different hosting scenarios where you may decide to expose your application by using a virtual directory.
For instance, you may decide to host the asp.net core web application in your own datacenter by using a windows virtual machine having IIS installed. In that case you may have an existing web site in IIS and you want to create a virtual application having a proper alias under that web site. Again in this scenario, as explained above for the azure windows app service, there is no reverse proxy involved and the kestrel web server is not used at all: the request is handled directly by the IIS worker process (in process hosting model).
Suppose that the public URL of your web site is https://sample-application.contoso.net and that you have chosen the sample-alias as the alias for the virtual application. This implies that all the requests to your asp.net core web application will have a path portion starting by sample-alias. For instance, when you want to require the home page of your application you will browse to https://sample-application.contoso.net/sample-alias.
In this case when you request the URL https://sample-application.contoso.net/sample-alias/foo/bar, the HttpRequest object in your application will be done in the following manner:
HttpRequest.Path will be set to /foo/bar
HttpRequest.PathBase will be set to sample-alias
Due to the way the default web host for an ASP.NET core application is built, this scenario involving IIS virtual applications works out of the box and the middleware pipeline is aware of the common prefix to all the incoming HTTP requests and it is able to set the path base to sample-alias and the path property to the remaining part of the incoming request's path (/foo/bar in my example above).
As a rule of thumb, you can consider that an ASP.NET core web application works fine without any additional configurations when you want to host it by using IIS. This is true for the path base property too (check here to verify that the request base path is set automatically inside your application at the stratup).
As a last example consider hosting your application on a Linux machine, by using nginx as a reverse proxy. In this case your application will be executed inside the kestrel web server, but it won't be directly exposed to the public internet. The thing being exposed to the public internet is the nginx web server which routes the incoming HTTP requests to the kestrel web server (where your application is executed). You may decide to configure your nginx so that all requests starting by the prefix /awesome-application will be routed to your asp.net core web application.
As an example, suppose to expose nginx to the public internet at the URL https://ingress.contoso.net: in this case if you want to request the home page of your application you need to browse to https://ingress.contoso.net/awesome-application/.
In this case you can't get the awesome-application request path base for free (by default, kestrel is not aware of it and it considers the request path base to be string.empty).
In order to make kestrel aware of the request path base you need to use the UsePathBaseMiddleware as the first item in your middleware pipeline.
If you need more details for this case, follow this documentation and see also this stackoverflow question.
I've got a stand alone WCF service providing REST services. As time goes on, I'm feeling like MS is going to reduce support for WCF and REST services, and I've already had to code in a bunch of hacks to get somethings working like CORS. Additionally, implementing https is another hack since it requires using OS functionality. (i.e. you have to install the certificate using an external application, which doesnt' make the service very self contained)
In anycase, I'm considering either a move to ASP.NET REST API and OWIN, or Java/Spring. I wanted to first see what it would take to move to ASP.NET REST, since I figured that should take the smallest amount of work, but I haven't found any good examples.
There's a pretty straightforward example on the asp.net site.
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
setup a self-contained project i.e console app or windows service
initialise and setup you routes
create your Controller / API stubs
deploy
Regarding SSL, whether it's IIS or Apache you will have to configure it on the web server regardless.
Is it possible to use a self hosted signalR server with an MVC(4) application such that it is totally seperate from the signalR server?
I tried Tim and Patrick's beautifully executed SignalR intro tutorial, and was wondering if I could try that? And even if I could, would that offer any performance advantages over an integrated service as is metioned in the tutorial.
It is absolutely possible to self-host a SignalR 2.0 server with OWIN and accessing this server from within any Website (which may be a MVC application). The only thing you need is to enable CORS (app.UseCors(CorsOptions.AllowAll); in your Startup file of the Owin Host) since it's not on the same domain as your Website. Obviously you can't use SignalR within the MVC application itself this way (e.g. to publish messages).
I'm using a self-hosted ASP.NET Web API 2 and SignalR 2 server with OWIN to serve data to clients. You can find an example server using this scenario here. Tho advantage in this approach is to have your views & styles sepparated from your data and business logic. Making everything very easy to cache and scale.
I am developping a web application project in Visual Studio 2005 on .NET 2.0 the web application project has obviously secured web pages and web services. I want to secure the web services as well. Currently the authentication mode in the web.config is set to forms and I have created my own membership provider for this purpose.
The target application server is IIS 5.0 which is configured to work over https with a valid certificate so technically speaking all I want is the web services to validate some hard coded string to ensure that the system that call them are known since they manipulate sensitive data. Since its over a secured channel I do not expect to use any fancy encryption for this web service authentication. As a side note, the expected system to use the web services are in Java and not in .NET
What I am really looking for is the best way for me to achieve this within the same solution in visual studio. I do not want the web services to be a separated project. (requirement)
Is the only solution to use flow credentials in the SOAP header ?
Thanks,
Carl T.
You can add a location element to your web.config with an authorization element that allows anonymous users to access the web service, effectively bypassing the forms security for the service. Then you can make your hardcoded string be accepted as just another argument to your methods. See location Element (ASP.NET Settings Schema) for more information.
You mentioned hard-coded strings, so I assumed you were looking to pass it to methods and run sessionless. Give this article a look .NET Web Services Security. The part you'll be most interested in is on page 3.
Ideally, you should look to update to .NET 3.5 or higher with WCF, but barring that these are your best bets.