I've updated from Microsoft.AspNet.OData version 6.0.0 to OData version 7.0.1. The upgrade has broken my ability to get the Id from a path when linking one object to another. Here is my Web API call to add a role to a specific user using the OData standard:
POST: http://localhost:61506/odata/users('bob')/roles/$ref
Request body: {"#odata.id":"http://localhost:61506/odata/roles(1)"}
The Web API method verifies the user and then makes a call to Helpers.GetKeyFromUri to get the role Id value from the request body.
[HttpPost, HttpPut]
public IHttpActionResult CreateRef([FromODataUri] string key, string navigationProperty, [FromBody] Uri link)
{
// Ensure the User exists
User user = new User().GetById(key);
if (user == null)
{
return NotFound();
}
// Determine which navigation property to use
switch (navigationProperty)
{
case "roles":
// Get the Role id
int roleId;
try
{
roleId = Helpers.GetKeyFromUri<int>(Request, link);
}
catch (Exception ex)
{
return BadRequest();
}
// Ensure the Role exists
Role role = new Role().GetById(roleId);
if (role == null)
{
return NotFound();
}
// Add the User/Role relationship
user.Roles.Add(role);
user.Update();
break;
default:
return StatusCode(HttpStatusCode.NotImplemented);
}
return StatusCode(HttpStatusCode.NoContent);
}
That function looks like this (Originally from here but with updated references: https://github.com/OData/ODataSamples/blob/master/RESTier/Trippin/Trippin/Helpers.cs)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Net.Http;
using System.Web.Http.Routing;
using Microsoft.AspNet.OData.Extensions;
using Microsoft.AspNet.OData.Routing;
using Microsoft.OData.UriParser;
namespace Project1.Extensions
{
public class Helpers
{
public static TKey GetKeyFromUri<TKey>(HttpRequestMessage request, Uri uri)
{
if (uri == null)
{
throw new ArgumentNullException("uri");
}
var urlHelper = request.GetUrlHelper() ?? new UrlHelper(request);
var pathHandler = (IODataPathHandler)request.GetRequestContainer().GetService(typeof(IODataPathHandler));
string serviceRoot = urlHelper.CreateODataLink(
request.ODataProperties().RouteName,
pathHandler, new List<ODataPathSegment>());
var odataPath = pathHandler.Parse(serviceRoot, uri.LocalPath, request.GetRequestContainer());
var keySegment = odataPath.Segments.OfType<KeySegment>().FirstOrDefault();
if (keySegment == null)
{
throw new InvalidOperationException("The link does not contain a key.");
}
var value = keySegment.Keys.FirstOrDefault().Value;
return (TKey)value;
}
}
}
This line of code is now throwing the following error: Resource not found for the segment 'odata'
var odataPath = pathHandler.Parse(serviceRoot, uri.LocalPath, request.GetRequestContainer());
This worked fine when using OData 6.0.0 but fails in 7.0.1. It seems to have some sort of issue parsing my odata segment or not being able to find it at all. Here is my routing setup if it helps:
public static void Register(HttpConfiguration config)
{
// Setup the OData routes and endpoints
config.MapODataServiceRoute(
routeName: "ODataRoute",
routePrefix: "odata",
model: GetEdmModel());
// Enable OData URL querying globally
config.Count().Filter().Select().OrderBy().Expand().MaxTop(null);
}
I know I'm a bit late here, but I ran into this same problem with upgrading to Microsoft.AspNet.OData 7.x. After a bit of debugging and tinkering, I found that this code works for me - without having to remove the routePrefix:
public static TKey GetKeyFromUri<TKey>(HttpRequestMessage request, Uri uri)
{
if (uri == null)
{
throw new ArgumentNullException(nameof(uri));
}
var urlHelper = request.GetUrlHelper() ?? new UrlHelper(request);
string serviceRoot = urlHelper.CreateODataLink(
request.ODataProperties().RouteName,
request.GetPathHandler(),
new List<ODataPathSegment>());
var odataPath = request.GetPathHandler().Parse(
serviceRoot,
uri.AbsoluteUri,
request.GetRequestContainer());
var keySegment = odataPath.Segments.OfType<KeySegment>().FirstOrDefault();
if (keySegment == null)
{
throw new InvalidOperationException("The link does not contain a key.");
}
return (TKey)keySegment.Keys.FirstOrDefault().Value;
}
It turns out that IODataPathHandler.Parse(...) can take an absolute URI and resolve it against the serviceRoot.
The other key difference is that KeySegment.Keys already has a mapping of Key-Values, where the value is already parsed - it just needs to be casted.
For reference, I am using Microsoft.AspNet.OData 7.4.0
Hope this helps!
I caused myself the same problem by changing routePrefix from null to odata just like you've done. Setting routePrefix to null will allow your code to work perfectly fine as long as you don't need a route prefix (such as /odata/).
Related
After many tries and read articles I decided to place my issue here. What I want is the following: I am working on api-versioning of an application. A supported version format by .NET Core (Microsoft.AspNetCore.Mvc.Versioning package) is Major.Minor, and this is what I want to use in the project I work on. What I want is to have is a fall-back version in case when the minor version is not specified by the client.
I am using .NET core 2.2, and using api-version specified in the header. The corresponding API versioning config looks like this:
services.AddApiVersioning(options => {
options.ReportApiVersions = true;
options.ApiVersionReader = new HeaderApiVersionReader("api-version");
options.ErrorResponses = new ApiVersioningErrorResponseProvider();
});
I have the following two controllers for each version: (the controllers are simplified for the sake of this SO question):
[ApiVersion("1.0")]
[Route("api/[controller]")]
public class ValueControllerV10 : Controller
{
[HttpGet(Name = "collect")]
public String Collect()
{
return "Version 1.0";
}
}
[ApiVersion("1.1")]
[Route("api/[controller]")]
public class ValueControllerV11 : Controller
{
[HttpGet(Name = "collect")]
public String Collect()
{
return "Version 1.1";
}
}
If the client specifies api-version=1.0 then the ValueControllerV10 is used. And of course if the client specifies api-version=1.1, then the ValueControllerV11 is used, as expected.
And now comes my problem. If the client specifies api-version=1 (so only the major version without the minor version), then the ValueControllerV10 is used. It is because ApiVersion.Parse("1") is equal to ApiVersion.Parse("1.0"), if i am not mistaken. But what I want in this case is to invoke the latest version of the given major version, which is 1.1 in my example.
My attempts:
First: Specifying [ApiVersion("1")] at ValueControllerV11
[ApiVersion("1")]
[ApiVersion("1.1")]
[Route("api/[controller]")]
public class ValueControllerV11 : Controller
{
[HttpGet(Name = "collect")]
public String Collect()
{
return "Version 1.1";
}
}
It does not work, it leads
AmbiguousMatchException: The request matched multiple endpoints
To solve this, I have came up with the second approach:
Second: using custom IActionConstraint. For this I followed these articles:
https://stevenknox.net/aspnet-core-mvc-action-priority-using-actionconstraints/
https://www.strathweb.com/2017/06/using-iactionconstraints-in-asp-net-core-mvc/
I have then created the following class:
[AttributeUsage(AttributeTargets.Method)]
public class HttpRequestPriority : Attribute, IActionConstraint
{
public int Order
{
get
{
return 0;
}
}
public bool Accept(ActionConstraintContext context)
{
var requestedApiVersion = context.RouteContext.HttpContext.GetRequestedApiVersion();
if (requestedApiVersion.MajorVersion.Equals(1) && !requestedApiVersion.MinorVersion.HasValue)
{
return true;
}
return false;
}
}
And used at ValueControllerV11:
[ApiVersion("1")]
[ApiVersion("1.1")]
[Route("api/[controller]")]
public class ValueControllerV11 : Controller
{
[HttpGet(Name = "collect")]
[HttpRequestPriority]
public String Collect()
{
return "Version 1.1";
}
}
Well, it solves the AmbiguousMatchException, but overrides the default behaviour of Microsoft.AspNetCore.Mvc.Versioning package so if the client uses api-version 1.1, then she get a 404 Not Found back, which is understandable according to the implementation of HttpRequestPriority
Third: Using MapSpaFallbackRoute in Startup.cs, conditionally:
app.MapWhen(x => x.GetRequestedApiVersion().Equals("1") && x.GetRequestedApiVersion().MinorVersion == null, builder =>
{
builder.UseMvc(routes =>
{
routes.MapSpaFallbackRoute(
name: "spa-fallback",
defaults: new {controller = nameof(ValueControllerV11), action = "Collect"});
});
});
app.UseMvc();
It does not work either, no any impact. The name MapSpaFallbackRoute gives me also a feeling that it is not what I need to use...
So my question is: How can I introduce a fallback 'use latest' behaviour for the case when the minor version is not specified in api-version? Thanks in advance!
This is intrinsically not supported out-of-the-box. Floating versions, ranges, and so on are contrary to the principles of API Versioning. An API version does not, and cannot, imply any backward compatibility. Unless you control both sides in a closed system, assuming that a client can handle any contract change, even if you only add one new member, is a fallacy. Ultimately, if a client asks for 1/1.0 then that's what they should get or the server should say it's not supported.
My opinion aside, some people still want this type of behavior. It's not particularly straight forward, but you should be able to achieve your goal using a custom IApiVersionRoutePolicy or custom endpoint matcher - it depends on the style of routing you're using.
If you still using the legacy routing, this may be the easiest because you just create a new policy or extend the existing DefaultApiVersionRoutePolicy by overriding OnSingleMatch and register it in your service configuration. You'll know it's the scenario you're looking for because the incoming API version will not have the minor version. You are correct that 1 and 1.0 will equate as the same, but the minor version is not coalesced; therefore, ApiVersion.MinorVersion will be null in this scenario.
If you're using Endpoint Routing, you'll need to replace the ApiVersionMatcherPolicy. The following should be close to what you want to achieve:
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Abstractions;
using Microsoft.AspNetCore.Mvc.Routing;
using Microsoft.AspNetCore.Mvc.Versioning;
using Microsoft.AspNetCore.Routing;
using Microsoft.AspNetCore.Routing.Matching;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using static Microsoft.AspNetCore.Mvc.Versioning.ApiVersionMapping;
public sealed class MinorApiVersionMatcherPolicy : MatcherPolicy, IEndpointSelectorPolicy
{
public MinorApiVersionMatcherPolicy(
IOptions<ApiVersioningOptions> options,
IReportApiVersions reportApiVersions,
ILoggerFactory loggerFactory )
{
DefaultMatcherPolicy = new ApiVersionMatcherPolicy(
options,
reportApiVersions,
loggerFactory );
Order = DefaultMatcherPolicy.Order;
}
private ApiVersionMatcherPolicy DefaultMatcherPolicy { get; }
public override int Order { get; }
public bool AppliesToEndpoints( IReadOnlyList<Endpoint> endpoints ) =>
DefaultMatcherPolicy.AppliesToEndpoints( endpoints );
public async Task ApplyAsync(
HttpContext httpContext,
EndpointSelectorContext context,
CandidateSet candidates )
{
var requestedApiVersion = httpContext.GetRequestedApiVersion();
var highestApiVersion = default( ApiVersion );
var explicitIndex = -1;
var implicitIndex = -1;
// evaluate the default policy
await DefaultMatcherPolicy.ApplyAsync( httpContext, context, candidates );
if ( requestedApiVersion.MinorVersion.HasValue )
{
// we're done because a minor version was specified
return;
}
var majorVersion = requestedApiVersion.MajorVersion;
for ( var i = 0; i < candidates.Count; i++ )
{
// make all candidates invalid by default
candidates.SetValidity( i, false );
var candidate = candidates[i];
var action = candidate.Endpoint.Metadata?.GetMetadata<ActionDescriptor>();
if ( action == null )
{
continue;
}
var model = action.GetApiVersionModel( Explicit | Implicit );
var maxApiVersion = model.DeclaredApiVersions
.Where( v => v.MajorVersion == majorVersion )
.Max();
// remember the candidate with the next highest api version
if ( highestApiVersion == null || maxApiVersion >= highestApiVersion )
{
highestApiVersion = maxApiVersion;
switch ( action.MappingTo( maxApiVersion ) )
{
case Explicit:
explicitIndex = i;
break;
case Implicit:
implicitIndex = i;
break;
}
}
}
if ( explicitIndex < 0 && ( explicitIndex = implicitIndex ) < 0 )
{
return;
}
var feature = httpContext.Features.Get<IApiVersioningFeature>();
// if there's a match:
//
// 1. make the candidate valid
// 2. clear any existing endpoint (ex: 400 response)
// 3. set the requested api version to the resolved value
candidates.SetValidity( explicitIndex, true );
context.Endpoint = null;
feature.RequestedApiVersion = highestApiVersion;
}
}
Then you'll need to update you service configuration like this:
// IMPORTANT: must be configured after AddApiVersioning
services.Remove( services.Single( s => s.ImplementationType == typeof( ApiVersionMatcherPolicy ) ) );
services.TryAddEnumerable( ServiceDescriptor.Singleton<MatcherPolicy, MinorApiVersionMatcherPolicy>() );
If we consider a controller like this:
[ApiController]
[ApiVersion( "2.0" )]
[ApiVersion( "2.1" )]
[ApiVersion( "2.2" )]
[Route( "api/values" )]
public class Values2Controller : ControllerBase
{
[HttpGet]
public string Get( ApiVersion apiVersion ) =>
$"Controller = {GetType().Name}\nVersion = {apiVersion}";
[HttpGet]
[MapToApiVersion( "2.1" )]
public string Get2_1( ApiVersion apiVersion ) =>
$"Controller = {GetType().Name}\nVersion = {apiVersion}";
[HttpGet]
[MapToApiVersion( "2.2" )]
public string Get2_2( ApiVersion apiVersion ) =>
$"Controller = {GetType().Name}\nVersion = {apiVersion}";
}
When you request api/values?api-version=2, you'll match 2.2.
I'll reiterate that this is generally not a good idea as clients should be able to rely on stable versions. Using the status in the version may be more appropriate if you want pre-release APIs (ex: 2.0-beta1).
I hope that helps.
Well, the credits for answering the question goes to #Chris Martinez, on the other hand I could figure out another way to solve my issue:
I have namely created an extension for RouteAttribute, implementing IActionConstraintFactory:
public class RouteWithVersionAttribute : RouteAttribute, IActionConstraintFactory
{
private readonly IActionConstraint _constraint;
public bool IsReusable => true;
public RouteWithVersionAttribute(string template, params string[] apiVersions) : base(template)
{
Order = -10; //Minus value means that the api-version specific route to be processed before other routes
_constraint = new ApiVersionHeaderConstraint(apiVersions);
}
public IActionConstraint CreateInstance(IServiceProvider services)
{
return _constraint;
}
}
Where the IActionContraint looks like the following:
public class ApiVersionHeaderConstraint : IActionConstraint
{
private const bool AllowRouteToBeHit = true;
private const bool NotAllowRouteToBeHit = false;
private readonly string[] _allowedApiVersions;
public ApiVersionHeaderConstraint(params string[] allowedApiVersions)
{
_allowedApiVersions = allowedApiVersions;
}
public int Order => 0;
public bool Accept(ActionConstraintContext context)
{
var requestApiVersion = GetApiVersionFromRequest(context);
if (_allowedApiVersions.Contains(requestApiVersion))
{
return AllowRouteToBeHit;
}
return NotAllowRouteToBeHit;
}
private static string GetApiVersionFromRequest(ActionConstraintContext context)
{
return context.RouteContext.HttpContext.Request.GetTypedHeaders().Headers[CollectApiVersion.HeaderKey];
}
}
Then I can use the ApiVersionAttribute and my custom RouteWithVersionAttribute together, as follows:
[ApiVersion("1")]
[ApiVersion("1.1")]
[Route("collect", "1", "1.1")]
public class ValueControllerV11 : Controller
{
[HttpRequestPriority]
public String Collect()
{
return "Version 1.1";
}
}
Cheers!
what about the CurrentImplementationApiVersionSelector option, when registering the service? see here: https://github.com/microsoft/aspnet-api-versioning/wiki/API-Version-Selector
The CurrentImplementationApiVersionSelector selects the maximum API version available which does not have a version status. If no match is found, it falls back to the configured DefaultApiVersion. For example, if the versions "1.0", "2.0", and "3.0-Alpha" are available, then "2.0" will be selected because it's the highest, implemented or released API version.
services.AddApiVersioning(
options => options.ApiVersionSelector =
new CurrentImplementationApiVersionSelector( options ) );
My goal is to check if user is member of specific active directory group.
In .net mvc i was using this code inside my service
HttpContext.Current.Request.LogonUserIdentity.Groups
.Any(x => x.Translate(typeof(NTAccount)).Value == "some role"
and it worked well.
In .net core mvc 2.1.2 i pass IHttpContextAccessor into service constructor and try to use following
_httpAccessor.HttpContext.User.Identity.LogonUserIdentity.Groups
but there is an issue, because Identity does not contains LogonUserIdentity. I tried to find any solution but i was not successful, how can i get the list of user groups or check if user is member of specific one ?
Except using built-in function which check the permission by "Roles", if you want to check by specific AD Group, you can also use below codes :
public static class Security
{
public static bool IsInGroup(this ClaimsPrincipal User, string GroupName)
{
var groups = new List<string>();
var wi = (WindowsIdentity)User.Identity;
if (wi.Groups != null)
{
foreach (var group in wi.Groups)
{
try
{
groups.Add(group.Translate(typeof(NTAccount)).ToString());
}
catch (Exception)
{
// ignored
}
}
return groups.Contains(GroupName);
}
return false;
}
}
And using as:
if (User.IsInGroup("GroupName"))
{
}
I am needing to simultaneously support a query-parameter based route (/api/models?id=1) and a route based one (/api/models/1) while still allowing unambiguous access to the models collection (/api/models)?
My controller looks (something) like this:
[Route("/api/{controller}")]
public class ModelsController : Controller
{
[HttpGet]
public Models[] GetModels([FromQuery]QueryOptions queryOptions)
{
//...
}
[HttpGet("{id:int}")]
public Model Get([FromRoute] int id)
{
//...
}
[HttpGet("?{id:int}")]
public Model Get2Try1([FromQuery] int id)
{
//Fails with ": The literal section '?' is invalid.
//Literal sections cannot contain the '?' character."
//Which makes sense after some reading...
}
[HttpGet]
public Model Get2Try2([FromQuery] int id)
{
//Fails with "AmbiguousActionException: Multiple actions matched.
//The following actions matched route data and had all constraints satisfied:
//GetModels and Get2Try2"
//Which I think I understand as well...the absence of optional params
//means ambiguous routing...
}
[HttpGet] //What here?
public Model Get2Try3([FromQuery] int id) //and/or here?
{
}
}
I feel like there should be some way to (with declarative routing) accomplish this. Has anyone done anything along these lines?
Also, current code base is ASP.NET Core (RC1) to be upgraded to RTM/1.0 shortly. Details on either side are likely similar, but am interested in either/both.
I've found that the following works:
[HttpGet, Route("{id?}")]
... the key being mainly the '?'. You don't need any [FromX] in the method signature, this does the trick and caters for both query string and route parameter passing.
Unfortunately Swagger UI doesn't like it and expects some explicit parameter to work out of the box (https://github.com/domaindrivendev/Ahoy/issues/47 or https://github.com/domaindrivendev/Ahoy/issues/182), but that's another story :)
I had the same problem.
There aren't solutions that works (against wep api .net) with web api core.
If we set [Route("{id}")] and [Route("")] doesn't work; if we set only [Route("{id?}")] the query parameter is empty if I use querystring.
So, I've used a workround.
I used [Route("{id?}")], but inside the function I get param from Request.Query
Example
public T Cast<T>(string input)
{
T output = default(T);
if (string.IsNullOrWhiteSpace(input))
return output;
input = input.Trim();
try
{
Type typeToCastTo = typeof(T);
if (typeof(T).IsGenericType)
typeToCastTo = typeToCastTo.GenericTypeArguments[0];
if (typeToCastTo.IsEnum)
{
if (Enum.IsDefined(typeToCastTo, input))
return (T)Enum.Parse(typeToCastTo, input);
return output;
}
object value = Convert.ChangeType(input, typeToCastTo, CultureInfo.InvariantCulture);
return (value == null) ? output : (T)value;
}
catch
{
return output;
}
}
public void MapQuerystringParams<T>(ref T param, string name)
{
var q = Request.Query[name].FirstOrDefault();
if (q != null)
{
var cast = Cast<T>(q);
if (!cast.Equals(default(T)))
param = cast;
}
}
[Route("api/[controller]/[action]")]
[ApiController]
public class ActivityController : ControllerBase
{
//examples of call
//https://localhost:44345/api/Activity/GetActivityByCode/7000
//https://localhost:44345/api/Activity/GetActivityByCode/?Id=7000
[HttpGet]
[Route("{Id?}")]
public IActionResult GetActivityByCode(int Id)
{
MapQuerystringParams(ref Id, "Id"); //this take param from querystring if exists
ActivityBusiness business = new ActivityBusiness(new BusinessInitializer { config = configuration });
ActivityDTOModel activity = business.GetActivityByCode(Id);
return Ok(activity);
}
}
Ideally in the domain design if you can have one method serving one specific function then great. Recently I had to faithfully implement a legacy API and it wasn't an option for me to decompose the design of my API.
If you are suffering from ambiguous routes in MVC6 and need to differentiate unique Routes given specific QueryStrings that have been supplied at one single POST method. Then IActionConstraint can help! Here is some example code of me using it :
using System;
using Microsoft.AspNetCore.Mvc.ActionConstraints;
namespace Automation.Api.Service.Attributes
{
public class RoutingSpecificAttribute : Attribute, IActionConstraint
{
private string _keyParam;
public RoutingSpecificAttribute(string routingParameter)
{
this._keyParam = routingParameter;
}
public int Order
{
get
{
return 0;
}
}
public bool Accept(ActionConstraintContext context)
{
if (this._keyParam == null) { return true; }
switch (this._keyParam)
{
case "name": return context.RouteContext.HttpContext.Request.Query.ContainsKey(this._keyParam);
case "noquerystring": return context.RouteContext.HttpContext.Request.Query.Count == 0;
default:
return false;
}
}
}
}
This one method in the API that I needed to author both serviced a separate create + update functions based on the existence of a couple of QueryStrings: name & version.
So to help disambiguate you can distinctly decorate each of the methods within your controllers within said controller class [RoutingSpecific("noquerystring")] or [RoutingSpecific("name")] to help differentiate.
MSDN class description
Example implementation - see Entropy github
For anyone that happens to stumble upon this as I have,
Using .Net Core 3.1 the following works:
Web Controller Method
[HttpGet("something/{id}")]
public IActionResult Get([FromRoute] id, [FromQuery] OptionalParams optionalParams)
{
// do stuff
}
Query Parameter Container
public class OptionalParams
{
[FromQuery(Name = "colour_of_thing")]
public string Colour { get; set; }
[FromQuery(Name = "shape_of_thing")]
public string Shape { get; set; }
[FromQuery(Name = "some_other_filter")]
public string SomeOtherFilter { get; set; }
}
Url
var id = Guid.NewGuid();
var colour = "red";
var shape = "circle";
var url = $"Http://localhost:5000/something/{id}?colour_of_thing={colour}&shape_of_thing={shape}";
I am using a WCF Data Services class that exposes an entity framework model via the OData protocol like so:
public class Service : EntityFrameworkDataService<MyEntities>
{
public static void InitializeService(DataServiceConfiguration config)
{
config.UseVerboseErrors = true;
config.SetEntitySetAccessRule("*", EntitySetRights.All);
config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3;
}
}
I consume this service through a service reference in a web solution. I am having problems including all the navigation properties for the entity. I cannot use the following syntax because I do not know what type of entity the user may be requesting:
I CANNOT USE
MyEntities.Customer.Expand("Address");
or
MyEntities.Customer.Include("Address");
What I am currently doing is building a URI string with the $expand=Entity1,Entity2 syntax and then executing that against my service as follows:
public static QueryOperationResponse<object> GetList(string entitySetName, params string[] preloads)
{
StringBuilder stringBuilder = new StringBuilder();
string queryString = string.Empty;
object result = null;
Uri dataAccessURI;
stringBuilder.Append(ServiceReferenceURI.AbsoluteUri);
stringBuilder.Append(entitySetName);
if (preloads != null)
{
for (int i = 0; i <= preloads.Length - 1; i++)
{
queryString = i == 0 ? "?$expand=" : ",";
stringBuilder.AppendFormat("{0}{1}", queryString, preloads[i]);
}
}
dataAccessURI = new Uri(stringBuilder.ToString());
try
{
result = TitanEntities.Execute<object>(dataAccessURI, "GET", true);
}
catch (Exception ex)
{
// log any errors to the console
WriteConsoleMessage(ex.Message, DataAccessEventType.Error);
}
return (QueryOperationResponse<object>)result;
resulting URI string is similar to this:
http://192.168.0.196/Service.svc/AliquotPreparation?$expand=Aliquot,AliquotPrepBatch,AnalysisPreparationMethod,Unit,Employee,Unit,PreparationMethod,State
To me this is a crappy implementation. It is all I could come up with right now though. The problem is, if there are A LOT of navigation properties the $expand command gets too long and the URI reaches it's character limit!
So how can I implement this through a service reference? I would greatly appreciate someone's help!!!
inside my ASP.NET MVC controller, I've got a method that requires an HttpRequest object. All I have access to is an HttpRequestBase object.
Is there anyway I can somehow convert this?
What can/should I do??
You should always use HttpRequestBase and HttpResponseBase in your application as opposed to the concrete versions which are impossible to test (without typemock or some other magic).
Simply use the HttpRequestWrapper class to convert as shown below.
var httpRequestBase = new HttpRequestWrapper(Context.Request);
Is it your method, so you can re-write it to take HttpRequestBase? If not, you can always get the current HttpRequest from HttpContext.Current.HttpRequest to pass on. However, I often wrap access to the HttpContext inside a class like mentioned in ASP.NET: Removing System.Web Dependencies for better unit testing support.
You can just use
System.Web.HttpContext.Current.Request
The key here is that you need the full namespace to get to the "correct" HttpContext.
I know it's been 4 years since this question was asked, but if this will help somebody, then here you go!
(Edit: I see that Kevin Hakanson already gave this answer...so hopefully my response will help those people who just read answers and not comments.) :)
To get HttpRequest in ASP.NET MVC4 .NET 4.5, you can do the following:
this.HttpContext.ApplicationInstance.Context.Request
Try to use/create a HttpRequestWrapper using your HttpRequestBase.
Typically when you need to access the HttpContext property in a controller action, there is something you can do better design wise.
For example, if you need to access the current user, give your action method a parameter of type IPrincipal, which you populate with an Attribute and mock as you wish when testing. For a small example on how, see this blog post, and specifically point 7.
There is no way to convert between these types.
We had a similar case. We rewrote our classes/web services methods so that they use HttpContextBase, HttpApplicationStateBase, HttpServerUtilityBase, HttpSessionStateBase... instead of the types of close name without the "Base" suffix (HttpContext, ... HttpSessionState). They are a lot easier to handle with home-made mocking.
I feel sorry you couldn't do it.
This is an ASP.Net MVC 3.0 AsyncController which accepts requests, converts the inbound HttpRequestBase MVC object to a System.Web.HttpWebRequest. It then sends the request asynchronously. When the response comes back, it converts the System.Web.HttpWebResponse back into an MVC HttpResponseBase object which can be returned via the MVC controller.
To answer this question explicitly, I guess you'd only be interested in the BuildWebRequest() function. However, it demonstrates how to move through the whole pipeline - converting from BaseRequest > Request and then Response > BaseResponse. I thought sharing both would be useful.
Through these classes, you can have an MVC server which acts as a web proxy.
Hope this helps!
Controller:
[HandleError]
public class MyProxy : AsyncController
{
[HttpGet]
public void RedirectAsync()
{
AsyncManager.OutstandingOperations.Increment();
var hubBroker = new RequestBroker();
hubBroker.BrokerCompleted += (sender, e) =>
{
this.AsyncManager.Parameters["brokered"] = e.Response;
this.AsyncManager.OutstandingOperations.Decrement();
};
hubBroker.BrokerAsync(this.Request, redirectTo);
}
public ActionResult RedirectCompleted(HttpWebResponse brokered)
{
RequestBroker.BuildControllerResponse(this.Response, brokered);
return new HttpStatusCodeResult(Response.StatusCode);
}
}
This is the proxy class which does the heavy lifting:
namespace MyProxy
{
/// <summary>
/// Asynchronous operation to proxy or "broker" a request via MVC
/// </summary>
internal class RequestBroker
{
/*
* HttpWebRequest is a little protective, and if we do a straight copy of header information we will get ArgumentException for a set of 'restricted'
* headers which either can't be set or need to be set on other interfaces. This is a complete list of restricted headers.
*/
private static readonly string[] RestrictedHeaders = new string[] { "Accept", "Connection", "Content-Length", "Content-Type", "Date", "Expect", "Host", "If-Modified-Since", "Range", "Referer", "Transfer-Encoding", "User-Agent", "Proxy-Connection" };
internal class BrokerEventArgs : EventArgs
{
public DateTime StartTime { get; set; }
public HttpWebResponse Response { get; set; }
}
public delegate void BrokerEventHandler(object sender, BrokerEventArgs e);
public event BrokerEventHandler BrokerCompleted;
public void BrokerAsync(HttpRequestBase requestToBroker, string redirectToUrl)
{
var httpRequest = BuildWebRequest(requestToBroker, redirectToUrl);
var brokerTask = new Task(() => this.DoBroker(httpRequest));
brokerTask.Start();
}
private void DoBroker(HttpWebRequest requestToBroker)
{
var startTime = DateTime.UtcNow;
HttpWebResponse response;
try
{
response = requestToBroker.GetResponse() as HttpWebResponse;
}
catch (WebException e)
{
Trace.TraceError("Broker Fail: " + e.ToString());
response = e.Response as HttpWebResponse;
}
var args = new BrokerEventArgs()
{
StartTime = startTime,
Response = response,
};
this.BrokerCompleted(this, args);
}
public static void BuildControllerResponse(HttpResponseBase httpResponseBase, HttpWebResponse brokeredResponse)
{
if (brokeredResponse == null)
{
PerfCounters.ErrorCounter.Increment();
throw new GriddleException("Failed to broker a response. Refer to logs for details.");
}
httpResponseBase.Charset = brokeredResponse.CharacterSet;
httpResponseBase.ContentType = brokeredResponse.ContentType;
foreach (Cookie cookie in brokeredResponse.Cookies)
{
httpResponseBase.Cookies.Add(CookieToHttpCookie(cookie));
}
foreach (var header in brokeredResponse.Headers.AllKeys
.Where(k => !k.Equals("Transfer-Encoding", StringComparison.InvariantCultureIgnoreCase)))
{
httpResponseBase.Headers.Add(header, brokeredResponse.Headers[header]);
}
httpResponseBase.StatusCode = (int)brokeredResponse.StatusCode;
httpResponseBase.StatusDescription = brokeredResponse.StatusDescription;
BridgeAndCloseStreams(brokeredResponse.GetResponseStream(), httpResponseBase.OutputStream);
}
private static HttpWebRequest BuildWebRequest(HttpRequestBase requestToBroker, string redirectToUrl)
{
var httpRequest = (HttpWebRequest)WebRequest.Create(redirectToUrl);
if (requestToBroker.Headers != null)
{
foreach (var header in requestToBroker.Headers.AllKeys)
{
if (RestrictedHeaders.Any(h => header.Equals(h, StringComparison.InvariantCultureIgnoreCase)))
{
continue;
}
httpRequest.Headers.Add(header, requestToBroker.Headers[header]);
}
}
httpRequest.Accept = string.Join(",", requestToBroker.AcceptTypes);
httpRequest.ContentType = requestToBroker.ContentType;
httpRequest.Method = requestToBroker.HttpMethod;
if (requestToBroker.UrlReferrer != null)
{
httpRequest.Referer = requestToBroker.UrlReferrer.AbsoluteUri;
}
httpRequest.UserAgent = requestToBroker.UserAgent;
/* This is a performance change which I like.
* If this is not explicitly set to null, the CLR will do a registry hit for each request to use the default proxy.
*/
httpRequest.Proxy = null;
if (requestToBroker.HttpMethod.Equals("POST", StringComparison.InvariantCultureIgnoreCase))
{
BridgeAndCloseStreams(requestToBroker.InputStream, httpRequest.GetRequestStream());
}
return httpRequest;
}
/// <summary>
/// Convert System.Net.Cookie into System.Web.HttpCookie
/// </summary>
private static HttpCookie CookieToHttpCookie(Cookie cookie)
{
HttpCookie httpCookie = new HttpCookie(cookie.Name);
foreach (string value in cookie.Value.Split('&'))
{
string[] val = value.Split('=');
httpCookie.Values.Add(val[0], val[1]);
}
httpCookie.Domain = cookie.Domain;
httpCookie.Expires = cookie.Expires;
httpCookie.HttpOnly = cookie.HttpOnly;
httpCookie.Path = cookie.Path;
httpCookie.Secure = cookie.Secure;
return httpCookie;
}
/// <summary>
/// Reads from stream into the to stream
/// </summary>
private static void BridgeAndCloseStreams(Stream from, Stream to)
{
try
{
int read;
do
{
read = from.ReadByte();
if (read != -1)
{
to.WriteByte((byte)read);
}
}
while (read != -1);
}
finally
{
from.Close();
to.Close();
}
}
}
}
It worked like Kevin said.
I'm using a static method to retrieve the HttpContext.Current.Request, and so always have a HttpRequest object for use when needed.
Here in Class Helper
public static HttpRequest GetRequest()
{
return HttpContext.Current.Request;
}
Here in Controller
if (AcessoModel.UsuarioLogado(Helper.GetRequest()))
Here in View
bool bUserLogado = ProjectNamespace.Models.AcessoModel.UsuarioLogado(
ProjectNamespace.Models.Helper.GetRequest()
);
if (bUserLogado == false) { Response.Redirect("/"); }
My Method UsuarioLogado
public static bool UsuarioLogado(HttpRequest Request)