I have developed .Net Core (5.0) application and its have SSO Login functionality.
This application is deployed on PCF and its having multiple instance
Now issue is while calling .Net Core methods using ajax call its giving below exception
Look 1st request goes in 1st instance and 2nd request goes in 2nd instance but 2nd instance not able to process the request how can we resolve this?
Related
I'm implementing profiler to track http requests coming to .net core applications hosted in IIS. I'm using coreclr profiling api to hook method enter/exit.
Which method I should track to know a new http request coming into my application.
Create a middle ware and configure ASP.NET Core to use it. It should receive requests, process it, then pass it along with the pipeline.
For more information see here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-2.2
I currently have a restful api created using .Net Core. A third party can call my api and some additional calls are made from my api before returning a response.
In the situation that third parties request timeout / they cancel the request, what happens the request within the .net core api. Will it continue to stay alive and return a response or will the thread / call stop?
If it will stop, how can I ensure than this does not happen?
It depends on your implementation.
You can inject a CancellationToken to each controller endpoint and use it, to check whether a request has been canceled or not.
By default, when the browser cancels a request, that information is received from the server and the cancellation is being requested. The flag RequestAborted is then being set on the HttpContext available in each request or via the IHttpContextAccessor outside of controller endpoints.
Prior ASP.NET Core 2.0 there was a problem when using IIS as a reverse-proxy. It wouldn't recognize the cancellation of a request.
Some resources:
https://odetocode.com/blogs/scott/archive/2018/09/12/cancellationtokens-and-aborted-asp-net-core-requests.aspx
https://andrewlock.net/using-cancellationtokens-in-asp-net-core-mvc-controllers/
https://dev.to/joaofbantunes/using-cancellation-tokens-on-aspnet-core-mvc-actions-57hi
https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.http.httpcontext.requestaborted?view=aspnetcore-2.2
Creating simple asp.net core 2.0 web api application (RESTful services only) that uses windows authentication. In my controller I defined a simple test method which just returns the username (json format). When I used a restful client such as fiddler and invoke this method, e.g. http://localhost/webapi/testservice, I get a 401 Unauthorized error. However when I put that url in a Web browser, it invokes successfully and returns the user back.
My question is, why does invoking the service work on the browser but not in a REST client like Fiddler? Is there an additional header I need to add in the client when invoking the service?
I have a question about enabling cross-domain calls.
I have a WCF Rest service that is hosted in xyz domain. I am able to test these REST APIs from Advanced Rest Client, Postman and Fiddler. I also have a WPF application that actively calls these API which is hosted in a different domain (say abc domain) which works fine in getting responses.
However, when I created a new Angular web application and a Windows Service (deployed on abc domain), and tried calling the APIs from these two components, I am getting a 405 error.
Can someone explain:
How REST clients always are able to successfully establish a connection?
How does my WPF successfully connects to the WCF service even though
its on a different domain?
Why is my Windows Service/Web App not able to talk to WCF?
I assume that the issue here is caused by the preflight request. The browser issues this OPTIONS verb request to ask the server if the origin is allowed to call the API in a non-safe manner.
If your WCF REST service does not deal with this request, the WCF runtime will try to dispatch the request to your service implementation.
However, if the runtime does not find a method to call for this verb, it will return a 405 Method Not Allowed response.
I've dealt with this in the past by using an IOperationInvoker implementation, installed via an IOperationBehavior. This article describes a slightly different way of doing basically the same.
I'm using the WCF Web API (the latest version, which I think is 0.5, obtained from the VS2010 Ultimate integrated package dependency GUI).
I've got a simple API class exposed and in each method I'm making a call that performs authorization against the user. When the user is unauthorized, I throw an HttpResponseException with the 401/unauthorized code.
This works, and you can see that at some point in the Http Handler chain, the 401 was trapped. The problem is that the site in which the API resides contains ASP.NET Forms authentication... and so when it sees the 401, it tries to forward my client request to the logon page.
How do I disable this behavior for a particular sub-directory within my site? I've tried setting a location of "api" always allowing users... but I still throw a 401 which still causes ASP.NET to try and redirect me to the logon page.
I'm sure I'm just missing a simple configuration setting that tells forms auth to ignore requests for the /api/* directories, but I can't find any information on it.
I have described the problem and it's solution here (with Preview4): Basic Authentication with WCF Web API hosted in IIS / Getting a 404 - Disable Forms Authentication Redirection