AspNetCoreOData icon indicating copy to clipboard operation
AspNetCoreOData copied to clipboard

Unescaped '/' character in keys breaks the UriPathParser

Open vvdb-architecture opened this issue 3 years ago • 0 comments

Assemblies affected ASP.NET Core OData 8.x

Describe the bug Excel doesn't escape '/' characters in keys when calling OData endpoint. Therefore, the routing fails.

Reproduce steps Any key which is a string and has an unescaped '/' in it reproduces the problem. I.e. anything of the form https://myservice/odata/MyEntity('key/with/slashes')

Expected behavior The parser should not break.

Additional context There are open issues https://github.com/OData/odata.net/issues/735 and https://github.com/OData/odata.net/issues/2477 referring to the same problem. Even though http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part2-url-conventions/odata-v4.0-errata03-os-part2-url-conventions-complete.html#_Toc453752335 dictactes that the '/' character should be escaped, Excel doesn't do it. It would seem like a good idea to incorporate some more intelligence in parsing the segments than just blindly split on the '/' in order to process this and potentially other cases instead of counting on the clients to conform to the standard.

A workaround has been tried by attempting to replace the parser by a derived class implementing a "better way". The following is the configuration attempt:

		// this line exposes one or more OData endpoints (one per entity set, see GetEdmModel) with an "/odata/" route prefix.
		.AddOData(options => options
			.AddRouteComponents("odata", ODataModel.GetEdmModel(),
					configureServices =>
						configureServices.Replace(ServiceDescriptor.Scoped<UriPathParser, MyUriPathParser>())
			));

Even though it was verified that there was the original UriPathParser before the call to Replace and that MyUriParser is in the collection after the call to Replace, my implementation is never instantiated and never called.

The documentation https://learn.microsoft.com/en-us/odata/odatalib/uri-parser-path-extensibility refers to the extension possibility, but doesn't elaborate on the way to do the actual replacement. The document only mentions "Developers can define their own UriPathParser, register this class by DI (Please refer to [Dependency Injection support](../core libraries/2016-08-30-01-05-di-support)) ", which doesn't mean anything. I suspect that the documentation doesn't apply to ApNetCoreOData... but what is one to do then?

vvdb-architecture avatar Sep 29 '22 14:09 vvdb-architecture