Is it possible to use different EDM models for different users and different actions in the same controller?
Open
@xuzhg is already working on this.
Since Aug 17, 2021.
investigated
question
- Dominant language
- C#
- Stars
- 505
- Forks
- 186
- PR merge metrics
- No merged PRs in 30d
Description
I have some real-world problems with odata web api.
- We want to hide some sensitive fields in the entity class. Normal users or guests should not get these information. However, the resource owner or the system administrators still have the permission to get these fields. So I can not just remove the fields from the edm model.
- We want to allow the system administrators to use query options which may affect performance. But normal users should not perfrom these high-risk options.
- We want to use different models for CRUD actions in the same controller. For example, the
CreateTimeproperty should be returned by Get method, but it should not be included in the input model of Post method(obviously this field should be created by the service, not provided by the user). In traditional web apis, we can use a dto class to avoid over-posting. I don't know how to avoid over-posting in odata world. - For performance, we want to hide some long fields(long text or blob) in the Get method which return entity collection, but still expose these fields in the Get method which return a single entity instance.
I worked more with aspnetcore odata 7.x version rather than 8.x version, so I may miss some key progresses in the new version. If so, I will appreciate if anyone can give suggestions with the new version. Otherwise, I expect my problems can be sovled by 8.x version in the future.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.