Open msheluga opened 2 years ago
@msheluga short answer is "yes, you can change the model on ODataFeatures().Model.
However, for your scenario, can you share more details about your requirement?
so we are generating a model per user since the database is an aggregate of multiple systems to simplify the system. So a user would log in and would be handed their EDM at that time.
so for example
user A would have access to Books, Press
User B would have access to Books, Press, Distribution centers, etc.
We generate the EDM explicitly for the user so it contains the Entities they have access to, like above, and pass that back. From what I have read and tested it seems all to be correct since those Entities are placed in the model and the container of their EDM for access.
At the moment we've tried looking at ODataFeatures.Model and using it as a middleware class but it seems to break any update call (Patch/Post/etc) when we set the ODataFeatures().Model to the user's EDM. It seems to cause the Entity to always be null when we use that. We are using version 8.0.4 of the Microsoft.AspnetCore.OData nuget package and the project is .Net 5.0 Core in our testing.
@msheluga It looks "no problem". Can you share with me your repro for me to dig more?
https://github.com/msheluga/ODataBatching8/tree/Dynamic_EDM
pardon the commented out code, I was trying the OData features in the JWT middleware class the EDM is dynamically generated in the BooksContextService
please let me know if there are any issues accessing it
@msheluga OData routing match policy check path on odatafeature. see here: https://github.com/OData/AspNetCoreOData/blob/master/src/Microsoft.AspNetCore.OData/Routing/ODataRoutingMatcherPolicy.cs#L66
From your code at: https://github.com/msheluga/ODataBatching8/blob/Dynamic_EDM/ODataBatching8/Extensions/CustomODataRoutingMatcherPolicy.cs#L91, is there any scenario that only sets the model, but doesn't set the path?
If only the model set, it could go to OData routing match policy again and reset the model.
So the odataroutematchpolicy is the way to go with a dynamic edm? I did add the check for the odata path and update the branch
one more question about the dynamic edm
since we are using batching as well we need to apply some EDM when we provide the batching solution in the https://github.com/msheluga/ODataBatching8/blob/594bce4c935a9624498ca8218fc56c0559cb6603/ODataBatching8/Startup.cs#L49
Is there another way? for security purposes I would like to provide either at that point an empty EDM or no EDM until I know the user is authorized inside the ODataMatcthPolicy.
I have the problem where we want to provide an edm per user but we want to just restrict/remove the tables/fields that the user is not allowed to see. The solution provided above won't work since these EDMs can be generated each time there is a new user and we can't just add another model.
I see that you can change the model on a Get method via middleware and using the ODataFeature().Model Is there a way to do this doe post/patch/put?