I have inherited a project that uses Dynamic Data. The solution has a project with source code called NotAClue.Web.DynamicData. There are several places in the code that use attributes from the NotAClue project (e.g. [SecureTable(CombinedActions.Full, "Admin")].
Everything is working fine.
I have 2 questions:
1. I am now trying to make a change to handle a case for a user who has 2 roles 'Staff' and 'Intake'. I have a table called Claim to which 'Staff' role must have full rights but 'Intake' role must only have Readonly. I thought I could handle this by ordering
the placement of SecureTable attributes like this: (the restrictive condition at the bottom)
[SecureTable(CombinedActions.Full, "Staff")]
[SecureTable(CombinedActions.ReadOnly, "Intake")]
public partial class Claim
However, for a user who has both roles 'Staff', and 'Intake', the user can still edit/delete etc. What is the way to explicitly deny 'Intake' user role to this table.
2. I would like to use a nugget package instead of having the code for NotAClue.Web.DynamicData locally in the solution. But when I installed the NotAClue.DynamicData.Extensions (version 1.2.1.1) package, I could not find SecureTable attribute. In fact I
could not find anything close to this attribute. However, looking at the code on ddextensions.codeplex.com, there is a SecureTable attribute in the NotAClue.ComponentModel.DataAnnotations namespace. So is the nuget package not updated with the latest code
from ddextensions.codeplex.com. Also, on codeplex, this project us marked as Alpha..so is there a more recent version of this code available elsewhere?
What you need to do here is change the way the security is checked: you need to look in the SecureDynamicDataRouteHandler code and it's CreateHandler method there will be a line of code like this
it's the HasAny method that you will need to change, what you are saying is the MOST restrictive permission wins so you will need to weigh the "allowedSecuredAction" and select the most restrictive. The current code is most permissive.
See my blog C# Bits | Twitter @sjnaughton Always seeking an elegant solution.
None
0 Points
16 Posts
Question regarding Dynamic Data Role Based Security
Jul 17, 2014 03:32 PM|jbliss1234|LINK
I have inherited a project that uses Dynamic Data. The solution has a project with source code called NotAClue.Web.DynamicData. There are several places in the code that use attributes from the NotAClue project (e.g. [SecureTable(CombinedActions.Full, "Admin")]. Everything is working fine.
I have 2 questions:
1. I am now trying to make a change to handle a case for a user who has 2 roles 'Staff' and 'Intake'. I have a table called Claim to which 'Staff' role must have full rights but 'Intake' role must only have Readonly. I thought I could handle this by ordering the placement of SecureTable attributes like this: (the restrictive condition at the bottom)
However, for a user who has both roles 'Staff', and 'Intake', the user can still edit/delete etc. What is the way to explicitly deny 'Intake' user role to this table.
2. I would like to use a nugget package instead of having the code for NotAClue.Web.DynamicData locally in the solution. But when I installed the NotAClue.DynamicData.Extensions (version 1.2.1.1) package, I could not find SecureTable attribute. In fact I could not find anything close to this attribute. However, looking at the code on ddextensions.codeplex.com, there is a SecureTable attribute in the NotAClue.ComponentModel.DataAnnotations namespace. So is the nuget package not updated with the latest code from ddextensions.codeplex.com. Also, on codeplex, this project us marked as Alpha..so is there a more recent version of this code available elsewhere?
Thanks
All-Star
17915 Points
5679 Posts
MVP
Re: Question regarding Dynamic Data Role Based Security
Jul 17, 2014 06:24 PM|sjnaughton|LINK
What you need to do here is change the way the security is checked: you need to look in the SecureDynamicDataRouteHandler code and it's CreateHandler method there will be a line of code like this
it's the HasAny method that you will need to change, what you are saying is the MOST restrictive permission wins so you will need to weigh the "allowedSecuredAction" and select the most restrictive. The current code is most permissive.
Always seeking an elegant solution.