-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide an option on FromRouteAttribute that allows decoding the value being bound #11544
Comments
Thanks for contacting us, @SchroterQuentin. |
The problem exist on [HttpGet] [HttpPost] [HttpPut] etc. Is there a way to handle all this problems in one area ? Or do we have to add this options on all this attributes ? I'm actually not understanding how would work this option ? |
Also see aspnet/Mvc#6388 The hosts partially decodes the percent encoding and explicitly skips decoding %2F here:
The main problem is Routing or MVC model binding cannot reliably decode the partially decoded segment. Ideally the server should not do any decoding especially not partial. (Full decoding is not possible since it would introduce new segments.) If the server behavior is not allowed to change (even behind a compatibility flag) then the router middleware could be modified to use the raw request url from IHttpRequestFetaure.RawTarget (which is not yet decoded) to get proper encoded tokens then decode as needed. A possible workaround: inject a middleware before routing takes place that restores the original undecoded path from IHttpRequestFeature.RawTarget then in another middleware after routing decode the RouteData tokens. |
As part of doing this, ensure binding to non-string values that require decoded values work. See #11134 |
Can we get an update on this? I just spent half an hour debugging my API before I found out that Route parameters are not URL decoded by default. |
Yeah, this behaviour is pretty weird. If you can't fix it then this FromRouteAttribute option would be a good compromise for me. Or perhaps provide an example implementation of the middleware suggested by https://github.com/Eilon in aspnet/Mvc#6388 |
I see that this bug lives since at least 2017 and there is not even a workaround about it. |
We will consider fixing this in the upcoming 5.0 release. That said, the plan is to not have this decoding on by default - you explicitly would have to opt-in to this behavior. For current releases, you should be able to unblock yourselves by explicitly url decoding values in your action that you know require to be decoded. |
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process. |
I face the same issue when passing encoded URI as part of route. In this case, |
Thanks for contacting us. We're moving this issue to the |
What am I missing? I can't understand that this isn't fixable in 6 years. It is very easy:
Examples (input string in unencoded form):
THERE IS NO SOLUTION FOR THIS PROBLEM POSSIBLE Is there any reason why route parameters should not be fully URL decoded, by default? I can think of none. And if there is, is it as devastating as the problem above? In short route parameter can not be used in asp .net core (unless you know all possible values in advance....) |
For me, this only happens when the controller inherits from ControllerBase class. The workaround for me is that instead of ControllerBase, I inherit the controller from the Controller class. |
@asprna I can not confirm this, for me it happens both with Controller and ControllerBase as base class. (Maybe this depends on the .net core version, after all this bug could have been fixed in 3.1) |
@Nils-Berghs I am currently using .net core 3.1 |
@Nils-Berghs Actually you are right. The actual workaround is to get the value from the query string.
|
What is the current state of this? It is another 3/4 of a year, when will we see a fix? |
Thanks for contacting us. We're moving this issue to the |
We are experiencing this issue and, running on Azure App Service, have yet to find a workaround other than switching to FromQuery which makes this one route inconsistent with all the others in our RESTful service. This issue needs to be fixed or a code example of a valid workaround which allows us to continue using FromRoute provided. |
BUMP, please stop development on .net 8, and fix bugs like this first....
More managers / scrum master than developers? |
cc @Tratcher |
The real fix here is much deeper: #30655. The server needs to make the path available as individual, fully decoded segments so that the the app / model binder isn't left dealing with this ambiguous escaping state. Routing would need to be updated to consume the path as individual segments. Model binding shouldn't need to be updated once routing is delivering the correct route values. |
Following the example from @celluj34 I made a sample app and library, don't judge the 5.0 references, that works for my purposes and addresses others concerns; namely @Nils-Berghs example and my own of raw "%2525" testcase. Feeling it's a bit unpolished for a nuget package but will decode the raw route - following some Angular influences I called "unsafe" - or if you want the controller to handle it uniquely it return back the raw value all by application level setup and controller level replacement of |
Sounds like they may never fix this: dotnet/aspnetcore#11544
I've just encountered this bug :( Is there any update on it? It would be nice to have some options that may change routing behavior for this specific case with slash encoding. [HttpGet("documents/for/{externalKeyId}/{documentType}")]
public async IAsyncEnumerable<Document> GetDocuments(
[FromRoute] string externalKeyId,
[FromRoute] DocumentType documentType,
[FromQuery] DateTime? startDate,
[FromQuery] DateTime? endDate,
[EnumeratorCancellation] CancellationToken cancel = default
) So as you can see keys with slashes inside are real pain in the neck. |
Having a use case for this at the moment, it is frustrating to have an incomplete decoded string. I am gonna go with the solution provided by @JMonsorno until a definitive solution is implemented. |
Here's my slightly simplified version of @JMonsorno's code that will apply the modified decoding behavior to all using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.ModelBinding;
using Microsoft.AspNetCore.Mvc.ModelBinding.Binders;
using Microsoft.AspNetCore.Mvc.ModelBinding.Metadata;
namespace My.Project.Namespace;
public class RouteUnsafeBinder : IModelBinder {
public Task BindModelAsync(ModelBindingContext bindingContext) {
ArgumentNullException.ThrowIfNull(bindingContext);
var modelName = bindingContext.ModelName;
// make sure the param we want was extracted in the standard method
// this will be the partially-decoded value that we're looking to avoid using here
if (!bindingContext.ActionContext.RouteData.Values.ContainsKey(modelName))
throw new NotSupportedException();
// wrap the param in curly braces so we can look for it in the [Route(...)] path
var templateToMatch = $"{{{modelName}}}";
// if this is null then the developer forgot the [Route(...)] attribute
var request = bindingContext.HttpContext.Request;
var template = (bindingContext.ActionContext.ActionDescriptor.AttributeRouteInfo?.Template)
?? throw new NotSupportedException();
// get the raw url that was called
var rawTarget = bindingContext.HttpContext.Features.Get<IHttpRequestFeature>()?.RawTarget
?? throw new NotSupportedException();
// strip the query string
var path = new Uri($"{request.Scheme}://{request.Host}{rawTarget}").AbsolutePath;
// go through route template and find which segment we need to extract by index
var index = template
.Split('/', StringSplitOptions.RemoveEmptyEntries)
.Select((segment, index) => new { segment, index })
.SingleOrDefault(iter =>
iter.segment.Equals(templateToMatch, StringComparison.OrdinalIgnoreCase))
?.index;
var segments = path.ToString().Split('/', StringSplitOptions.RemoveEmptyEntries);
if (index.HasValue) {
// extract and decode the target path segment
var rawUrlSegment = segments[index.Value];
var decoded = Uri.UnescapeDataString(rawUrlSegment);
bindingContext.Result = ModelBindingResult.Success(decoded);
} else {
// can't think of any scenarios where we'd hit this
throw new NotSupportedException();
}
return Task.CompletedTask;
}
}
public class FromRouteUnsafeModelBinder : IModelBinderProvider {
public IModelBinder? GetBinder(ModelBinderProviderContext context) {
if (context.Metadata is not DefaultModelMetadata metadata) return null;
var attribs = metadata.Attributes.ParameterAttributes;
return attribs == null
? null
// handle all [FromRoute] string parameters
: attribs.Any(pa => pa.GetType() == typeof(FromRouteAttribute))
&& metadata.ModelType == typeof(string)
? new BinderTypeModelBinder(typeof(RouteUnsafeBinder))
: null;
}
} I apply this binder at startup when I'm configuring services like this: services.AddControllers(opts => {
opts.ModelBinderProviders.Insert(0, new FromRouteUnsafeModelBinder());
}) |
The rights of my users are at
/api/admin/users/{userId}/rights
And my controller is as simple as
or
The problem I have is that, the userIds of my users may contains a
/
which is encoded to%2F
in the Uri. But userId doesn't decode%2F
so my string contains%2F
. It's fine for me, I can deal with that.But the userIds of my users may contains a
+
which is encoded to%2B
in the Uri. And now, the userId decode the%2B
to+
😲Currently, I can't use
. My only actual solution is to replace
WebUtility.UrlDecode(userId)
becauseuserId
may contains a+
which would be send as%2B
decoded as+
and finally to%2F
to/
which is ugly and does not solve all the possibility :%252F
I saw a recommandation to use
[FromQuery]
instead of[FromRoute]
but it's obvious that if both exist, it's because they have semantic difference.It seems that's not the first time the problem appears : aspnet/Mvc#4599, #2655, #4445 and I'd like to know if it's on the roadmap to change this behavior or not.
Could you please this time consider this bug ? I'd be happy to help.
The text was updated successfully, but these errors were encountered: