I was trying to work with the http context (with the help of Httpcontext.current) in the application_start event in global.asax then you will receive an Error:- HttpContext.Current Request is not available in this context.
The problem can easily be worked with a workaround by using a static constructor, which is fired when the object is accessed first. We can keep a flag in the Application_Beginrequest event and easily determine the request that initialized the application.
But in this case it gets created at every request, which is not required for me. I want to create or access Httpcontext.current once
My Code Is as Follows :-
`//var context = new HttpContextWrapper(HttpContext.Current);
//var routeData = RouteTable.Routes.GetRouteData(context) ?? new RouteData();
//var requestContext = new RequestContext(context, routeData);
//var urlHelper = new UrlHelper(requestContext);
//var url = urlHelper.Action("Home", "Index");
var httpContext = new HttpContextWrapper(HttpContext.Current);
UrlHelper urlHelper = new UrlHelper(new RequestContext(httpContext, new RouteData()));
if (urlHelper.RequestContext.HttpContext.Request.IsLocal)
{
}
//if (((requestContext.HttpContext).Request).IsLocal)
//{
//}`
There is no HttpContext nor HttpRequest instance in App_Start in integrated mode. You must work around this. If you really need to do something on first request, then register new BeginRequest handler in your global.asax and then unregister it when you are done.
Related
Simply passing Mock HttpContext to the controller context while unit testing logout functionality will throw following error
HttpContext.Signout + value can not be null (Parameter 'provider')
var mockHttpContext = new Mock<HttpContext>();
//set the controller HttpContext
_controller.ControllerContext.HttpContext = mockHttpContext.Object;
// Now call the Logout action method and Test result
If you drill down to the definition of SigOutAsync code it expect Authentication Service Provider which should not be null .
Hence , along with mocking HttpContext you also need to mock the service provider which will solve the issue .
//mock the Http Context along with Service provider
var mockHttpContext = new Mock<HttpContext>();
var authServiceMock = new Mock<IAuthenticationService>();
authServiceMock.Setup(_ => _.SignOutAsync(It.IsAny<HttpContext>(), It.IsAny<string>(),It.IsAny<AuthenticationProperties>())).Returns(Task.FromResult((object)null));
var serviceProviderMock = new Mock<IServiceProvider>();
serviceProviderMock.Setup(_ => _.GetService(typeof(IAuthenticationService)))
.Returns(authServiceMock.Object);
mockHttpContext.Setup(x => x.RequestServices)
.Returns(serviceProviderMock.Object);
//set the controller HttpContext
_controller.ControllerContext.HttpContext = mockHttpContext.Object;
// Now call the Logout and Test
Similar logic can be applied while testing SignIn functionality
Refer here as well- How to unit test HttpContext.SignInAsync()?
This seems to be a fairly common issue, but none of the SO articles I have looked at have solved this for me.
I am working on a ASP.NET WebForms/MVC application running on IIS on Windows 10 (so not IIS Express) which is using jQuery AJAX to invoke a WebAPI application on a separate server. To get around CORS issues, and to add additional processing to all API calls, we implemented a server-side proxy using MVC controllers, so each call would end up somewhere like this:
[HttpPost]
public ActionResult Timesheets_Submit(Timesheet data)
{
var processedData = ProcessTheRequestInSomeWay(data);
var client = new SdkClient();
var results = client.Timesheets.Post(processedData);
return Json(results);
}
And this all worked quite successfully.
However, we are getting rather fed up of having to implement new server-side proxy methods each time we add a new API endpoint, so we decided to create a transparent server-side proxy using WebAPI, and have that do the real work.
The transparent server-side proxy is implemented like this:
public class TransparentProxyDelegatingHandler : DelegatingHandler
{
private static readonly Uri BaseUri = new Uri("https://my.apiserver.com");
protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
request.Headers.Add("X-Forwarded-For", request.GetClientIpAddress());
request.RequestUri = new Uri(BaseUri, request.RequestUri.PathAndQuery.Replace("/Proxy", string.Empty));
ProcessRequestInSomeWay(request);
var response = await Client.SendAsync(request, HttpCompletionOption.ResponseHeadersRead, cancellationToken);
return response;
}
}
So a request to POST /Proxy/Timesheets will get translated into a call to POST https://my.apiserver.com/Timesheets and the response returned pretty much as-is.
The problem that I am having is that calls which use the PUT and DELETE verbs are being rejected as 404 Not Found by my UI (not by the API, I can still invoke that directly using e.g. Fiddler/Postman); the original proxy used those verbs, so it's not like they haven't been configured, it's just when I'm calling the delegating handler. The handler never gets invoked, so there's something happening in the routing engine that is causing MVC PUT/DELETE requests to work, but WebAPI PUT/DELETE requests to fail.
It turns out I was not registering the TransparentProxyDelegatingHandler correctly; I was registering it like this in my WebApiConfig:
configuration.MessageHandlers.Add(new TransparentProxyDelegatingHandler());
but as it turns out (thanks to https://blog.kloud.com.au/2013/11/24/do-it-yourself-web-api-proxy/), what I really wanted was:
configuration.Routes.MapHttpRoute(name: "proxy", routeTemplate: "proxy/{*path}",
handler: HttpClientFactory.CreatePipeline(
innerHandler: new HttpClientHandler(),
handlers: new DelegatingHandler[]
{
new TransparentProxyDelegatingHandler(),
}),
defaults: new { path = RouteParameter.Optional },
constraints: null);
I'm guessing that what was going on was that because I didn't have any actual ApiController implementations wired up to WebApi, it wasn't resolving correctly somehow in the early stages of the pipeline.
I'm trying to protect my webapi with IdentityServer and OpenID Connect using Autofac. I'm using OWIN. But for some reason I can't get claims of the user. It seems that AccessTokenValidation is not triggered at all. That makes me think there is something wrong in the order of my declarations at my startup. Here is my startup.
public class Startup {
public void Configuration(IAppBuilder appBuilder) {
// Add authentication
this.AddAuthentication(appBuilder);
HttpConfiguration config = new HttpConfiguration();
var container = CreateAutofacContainer();
var resolver = new AutofacWebApiDependencyResolver(container);
config.DependencyResolver = resolver;
WebApiConfig.Register(config);
config.EnsureInitialized();
// Register config - you can't add anything to pipeline after this
appBuilder.UseAutofacMiddleware(container);
appBuilder.UseAutofacWebApi(config);
appBuilder.UseWebApi(config);
}
private static IContainer CreateAutofacContainer() {
var autofacBuilder = new ContainerBuilder();
var assembly = Assembly.GetExecutingAssembly();
// Register your Web API controllers.
autofacBuilder.RegisterApiControllers(assembly);
// For general logging implementation
autofacBuilder.RegisterType<ConsoleLogger>().As<ILogger>();
// Create empty usage context to be filled in OWIN pipeline
IUsageContext usageContext = new RuntimeUsageContext();
autofacBuilder.RegisterInstance(usageContext).As<IUsageContext>().SingleInstance();
// We need to get usage context builded
autofacBuilder.RegisterType<OIDCUsageContextProvider>().InstancePerRequest();
var container = autofacBuilder.Build();
return container;
}
private void AddAuthentication(IAppBuilder app) {
var options = new IdentityServerBearerTokenAuthenticationOptions();
options.Authority = "MYAUTHORITY";
options.RequiredScopes = new[] { "openid", "profile", "email", "api" };
options.ValidationMode = ValidationMode.ValidationEndpoint;
app.UseIdentityServerBearerTokenAuthentication(options);
// Add local claims if needed
app.UseClaimsTransformation(incoming => {
// either add claims to incoming, or create new principal
var appPrincipal = new ClaimsPrincipal(incoming);
// incoming.Identities.First().AddClaim(new Claim("appSpecific", "some_value"));
return Task.FromResult(appPrincipal);
});
}
I'm using hybrid flow and api is called from SPA-application. I've verified (by calling my identity server's endpoint directly) that access token is valid and there are claims available. I also downloaded IdentityServer.AccessTokenValidation project and attached it as a reference. When I set some breakpoints to methods in that project, they never get called. That is why I think there is something wrong with my startup and OWIN pipeline.
I've declared UsageContext in my startup. It is a class I'm using to collect claims and some configuration settings - to be injected to actual controllers. I think it would be nice way to handle this, so in controllers there is always valid UsageContext available.
I've read a lot of samples and examples but still haven't found exactly same situation. I'll appreciate any attempts to point me into right direction.
Regards,
Borre
Could it be your registration of UsageContext as a Singleton? You mention this class contains claims, so this object should be resolved once pr http request - shouldn't it?
It turned out that there was some mysterious line in AccessTokenValidation - library that didn't work. I use that library to get claims. After changing the line everything seemed to work.
So basically my question is closed now and stuff works. But I'm still not totally convinced this is the right way to do this.
Thanks John for your comments!
i have Asp.netMVC form authentication and another authentication which im handle the request, to handle my version i use this code to create session and
httpcontex:
HttpContext ctx = HttpContext.Current;
FormsAuthentication.SetAuthCookie(username, true);
ctx.Session["UserName"] = username;
var identity = new GenericIdentity(username);
IPrincipal principal = new GenericPrincipal(identity, new[] { "User" });
Thread.CurrentPrincipal = principal;
ctx.User = principal;
it works correct but after my view loaded completely, i send an Ajax Request and in the action which ajax calls HttpContext.Request.IsAuthenticated is false how can i make the httpcontext valid for all requests?
I think that you need set an user in httpcontex
System.Web.HttpContext.Current.User = user;
For me it was because of my browser settings code.
I changed my setting in the browser and this fixed your problem.
Does anyone know how to get the current RequestContext from the Application_Error event in global.asax?? My problem is that i need to do a redirect, and thereby need to have the url generated using UrlHelper - which takes the aformentioned RequestContext.
While there is no direct way of accessing the RequestContext, you can create one yourself:
RequestContext context = new RequestContext(new HttpContextWrapper(HttpContext.Current), RouteTable.Routes.GetRouteData(new HttpContextWrapper(HttpContext.Current)))
So the UrlHelper can be constructed via:
UrlHelper helper = new UrlHelper(new RequestContext(new HttpContextWrapper(HttpContext.Current), RouteTable.Routes.GetRouteData(new HttpContextWrapper(HttpContext.Current))));
Not pretty, but it gets the job done.
You can access the request context using
HttpContext.Current.Request.RequestContext
Or, if you're in the Global.asax you can use
Context.Request.RequestContext
directly.
Create an HttpContextBase from the Current HttpContext, and from that you can generate a UrlHelper:
// Create Http Context Base from current Context
var contextBase = new System.Web.HttpContextWrapper(System.Web.HttpContext.Current);
// Get its request context
System.Web.Routing.RequestContext requestContext = contextBase.Request.RequestContext;
// Build url helper from request context
var urlHelper = new System.Web.Mvc.UrlHelper(requestContext);