-
Notifications
You must be signed in to change notification settings - Fork 711
Action parameter gets defined twice when using multiple odata routes #555
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
Comments
I'm afraid the real problem here is that OData isn't doing what you want or expect. The prefix is virtually cosmetic and doesn't mean anything to OData. The OData parser doesn't even consider it. OData was never designed to support multiple EDMs or handle duplicate routes. This makes it a challenge to implement API versioning. When you use the I seen a number of people try to use this approach and run into problems. Not to be overly critical, but there seems to be something inherently wrong with having duplicate entities, actions, etc with different behaviors that only vary by prefix (ex: students/classes vs teachers/classes). Classes should have the same meaning in both contexts, which would also negate the need for separate prefixes. Filtering classes by navigation property makes complete sense. While you've identified one issues, I'm not sure that is the end of it. Solving this issue may just lead to the next one. If you have a repro you can share, it would be useful. Ultimately, any time that you have a duplicate entity, etc that stripes across the prefix, you may hit this problem or something like it. There may be a solution to it yet, but it's a hard problem to solve. (e.g. there's way more to this than a simple bug fix - unfortunately). |
Hi, thanks for the quick and comprenhensive response. My use cases has more to do with permissions and multi-tenancy. Whenever I'm trying to access data from a tenant I navigate using /tenant/{tenant} prefix and has some EF filters that prohibits accessing other tenants data, and when I access with /host it means I'm acting as the platform itself giving me access to all the data. I guess I could make all the entities related to Tenant and only allow accessing them through tenant, but it presents other problems with multi level nested URL (e.g. /tenants/t1/Students/s1/Courses) What caught my attention was that if I use a Function instead of an Action all seems to work. I've included the sample repo I'm using. edit: I've updated the Repo with some code improvements |
There's a couple of other possibilities. Putting them in them in the same application is a convenience. One approach is to use completely separate applications. This would be a much better security and isolation boundary. You could then use host headers to give the impression to clients that they are actually talking to the same endpoint when they are, in fact, mapped separately behind the scenes. I won't pretend to know the particulars or idiosyncrasies of your application, but it certainly feels like there are authentication and authorization mechanisms you can use to identify yourself (or team) as rulers of the universe when you call into the API that would give you access to any tenant. To be fair, I won't rule out the possibility of a bug. The matrix of usage and combinations is very large and complex. Your repro will be useful in confirming that. It also illuminates a common scenario that may yet be solvable. Sorry that doesn't give you an immediate fix, but hopefully that moves you in the right direction. |
Hi, thanks for the pointers, knowing it's not a good way to have more than one OData route I will try to explore other solutions and ways of building this separation. As a side note, I tried registering the routes one by one, even having Sequence class excluded from one of the prefixes and the problem persists.
It seems that ApiExplorer is taking the values from the controllers it finds, even if it's not registered in the EdmModel for that versión and prefix. Best regards |
That's unfortunate. =/ Every time I run into this situation I feel like it should be solvable, but when I get down in the weeds, I end up hitting a roadblock. There is has to be a reliable solution to this yet! Thanks for the all the info. Real world configurations and challenges help flush out things out. Crossing my fingers there's a solution to this once and for all. :) |
I know it's been a while, but I wanted to add some clarifying notes. Is the problem limited to the API Explorer (e.g. generating OpenAPI/Swagger documents) or does the routing to the APIs themselves not work either. In reviewing this, I'm wondering if everything else may work except for the API Explorer stuff. Thanks. |
I managed to replicate this problem and I believe it's related to #667. You're 100% correct that The real issue seems to be a duplicate or otherwise ambiguous names. This should be the only way that As an aside, I'm working on a massive refactoring for the OData internals. I've come to the conclusion that |
Both of these issues are resolved in 5.0.0-RC.1. The official release will likely occur after 2 weeks of burn-in. If you encounter any issues, feel free to reopen the issue. Thanks. |
Uh oh!
There was an error while loading. Please reload this page.
Hi, I'm building a sample OData project with versioning in AspNet Core. And I've encountered a problem when trying to define an Action on one of my controllers.
When trying to build the swagger.json file the following Exception is thrown:
I declare two routes one for access by the users and another one for the services running by other components of the application.
My startup looks like this:
If I comment the line
builder.MapVersionedODataRoutes("host", "host", models);
everything works.The model where I declare my Action is:
And the controller is:
I tried to debug the problem using the source code and the problem seems to be that the method NewActionParameters is called once for each route declared, and doesn't check if the parameter was defined previously in the moduleBuilder, or use a different key for every mapping
Maybe changing this part can fix the issue
The text was updated successfully, but these errors were encountered: