I have an .aspx form with 20 fields that must be disable based on a users role and a status of a order record. Currently the application has 5 roles and 3 status, so I have 300 different possible conditions that I have to account for.
My first thought is to store each permutation in a table, then set the fields when the page loads by looping through the fields. Is there a better way? Please note, I am using .Net 2.0 and NOT MVC.
I'd probably store the details of each field, and then the roles and status that can edit them, and do it that way.
What are the rules for the system? Basically, are there really 300 possible conditions? Or is that really certain fields are only editable for certain status, and then only certain roles can edit those fields? Or is it that certain fields are available for certain roles as well?
If it's more of the former I'd probably have something like this:
Three primary tables (makes it easy to extend if you add a field, role or status):
Fields
Roles
Status
Then two link tables:
Field.Id and Role.Id
Field.Id and Status.Id
Then for any given order and user you can then find which Fields are editable for the order's current status, and the users role, and as you work through the fields set the access rights appropriately - however you set the controls - either dynamically generating them based on the collection you get back, or statically on the page.
If you have an issue where the Role can override the Status, you could also store a boolean in the Field/Role table, indicating whether the Field should be avaiable regardless of status.
Like another responder, we also use a Business Object framework called CSLA. CSLA implements field-level security checks by requiring class developers to do security checks in the property get/set calls. A typical property implementation looks like this:
Private mFirstName As String = ""
Public Property FirstName() As String
<System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _
Get
CanReadProperty("FirstName", True)
Return mFirstName
End Get
<System.Runtime.CompilerServices.MethodImpl(Runtime.CompilerServices.MethodImplOptions.NoInlining)> _
Set(ByVal value As String)
CanWriteProperty("FirstName", True)
If value Is Nothing Then value = ""
If Not mFirstName.Equals(value) Then
mFirstName = value
PropertyHasChanged("FirstName")
End If
End Set
End Property
Notice the calls to CanReadProperty and CanWriteProperty. The second parameter specifies that the method should throw an exception if the user is not authorized to perform the specific read/write operation.
The implementation of the CanReadProperty and CanWriteProperty are provided by the framework's base class but should be reproducible without adopting the entire CSLA framework. The implementations check an AuthorizationRules data structure which defines who is allowed/denied Read/Write access based on roles. Often, the AuthorizationRules structure is populated during object creation.
Exposing the same CanReadProperty and CanWriteProperty methods to your presentation-tier allows you to enable/disable UI elements based on the current user's access rights. For example:
FirstNameTextBox.ReadOnly = Not CanWriteProperty("FirstName", false)
Hopefully this information will provide you with a good starting point for developing your own implementation. If you're interested in learning more about CSLA then check out Expert C# 2008 Business Objects.
I suggest to use third party framework to achieve this. We use CSLA framework in our projects. It allow us to set authorization at field level.
Related
I'm creating an order form and a schema defined for an Order (certain required fields such as address, customer info, items selected and their quantities, etc).
a. User visits site.
b. A unique ID is generated for their session as well as a timestamp.
var userSession = {
_id: createId(),
timestamp: new Date(),
};
var sessionId = userSession._id;
c. The userSession is placed in local storage.
storeInLocalStorage('blahblah', sessionObject);
d. An Order object is created with the sessionId as the only field so far.
var newOrder = {
sessionId: sessionId;
};
e. Obviously at this point the Order object won't validate according to the schema so I can't store it in Mongo. BUT I still want to store it in Mongo so I can later retrieve incomplete orders, or orders in progress, using the sessionID generated on the user's initial visit.
This won't work because it fails validation:
Orders.insert(newOrder);
f. When a user revisits the site I want to be able to get the incomplete order from Mongo and resume:
var sessionId = getLocalStorage('blahblah')._id;
var incompleteOrder = Orders.findOne({'sessionId', sessionId});
So I'm not sure how to go about doing this while accomplishing these points.
I want full simpleschema validation on the Orders collection when the user is entering in items on the forms and when the user is intending to submit a full, complete order.
I want to disable simpleschema validation on the Orders collection and still allow storing into the DB so that partial orders can be stored for resumption at a later time.
I can make a field conditionally required using this here but that would mean 50+ fields would be conditionally required just for this scenario and that seems super cumbersome.
It sounds like you want to have your cake, and eat it too!
I think the best approach here would be keep your schema and validation on the Orders collection, but store incomplete orders elsewhere.
You could store them in another collection (with a more relaxed schema) if you want them on the server (possibly for enabling resume on another device for the logged in user) , or more simply in Local Storage, and still enable the resume previous order behaviour you are wanting.
Only write to the Orders collection when the order is complete (and passes validation).
Here's a variation on #JeremyK's answer: add an inProgress key to your order of type [Object]. This object would have no deeper validation. Keep your in progress order data in there until the order is final then copy/move all the relevant data into the permanent keys and remove the inProgress key. This would require that you make all the real keys optional of course. The advantage is that the object would maintain its primary key throughout the life cycle.
I think this particular case has been solved; but just in case, you can skip Simple Schemma validations by accessing MongoDB native API via Collection#rawCollection():
Orders.rawCollection().insert(newOrder);
While this question is very old in the meantime there is a better solution. You probably use simple schema together with collection2. Collection2 has the ability to set multiple schemas based on a selector and then validate against the correct schema based on it.
https://github.com/Meteor-Community-Packages/meteor-collection2#attaching-multiple-schemas-to-the-same-collection
e.g. you could have a selector {state: 'finished'} and only apply the full schema to these documents while having another selctor, e.g. {state: 'in-progress'} for unfinished orders with a schema with optional fields.
I've built a number sites using classic ASP type security and have continued using the same methods in ASP.NET. However, I now am looking for recommendations for a better or best practice way of doing it. I've read a few resource online but have not seen anything comprehensive enough that's applicable to what I'm trying to do. What I'm trying to do is apply user specific security that determines that user's access to specific pages, sections on that page, and fields in each section. It also needs to restrict access to various records as well and determine whether it's read or write privileges.
For those interested, here's how I've done it so far:
Because I lacked the know-how, here's how I did it using the old ASP classic way...
First, on the database side I have 4 relevant tables: tblUsers, tblRoles, tblPages, tblRecords (haven't gotten to sections and fields yet). Each user can belong to a "role" and the role then determines what pages they can access as well as what records they can access in various tables (there are a number of other tables in the db as well e.g. tblCustomers, tblSales, etc...). Each table includes these fields:
tblUsers: UserID, UserName, UserPwd
tblRoles: RoleID, RoleName, UserID
tblPages: PageID, PageName, RoleID
tblRecords: RecordID, RecordTable, RoleID
Now on the application side here's what I've done:
First, my login page is based on 1) looking up the user name and password in the tblUsers table and 2) if found, setting a session variable named "UserLoggedIn" = true. Then on every page load event I check if the UserLoggedIn session is set to true, if so, continue... if not clear all session variables (log out) and send the user back to the login page. The old classic ASP way of doing it.
Second, with the login set up, to control page access, when the user is logged in I created another session variable that holds a pipe delimited string of all the pages that user can access (e.g. Session("PageAccess") = "{1|3|10|8}"). Then in each page's load event I've explicitly added a variable/constant that uniquely identifies that page (e.g. pageone.aspx has Dim PageID As String = 1). Then I check to see if the PageID matches an ID stored in the PageAccess session. If it does, continue... If it doesn't I send them to the home page.
Third/Last, for the records access, I did the same thing. When the user is logged in I created a session variable that hold a pipe delimited string of all the records the user could access along with the table it's related to (e.g. Session("RecordAccess") = "{tblCustomrs||1|5|7}" and checked it and applied it basically the same way as the page session variable.
My Solution is :(it worked for my projects)
tables : tblUser , tblRole ,
tblUserInRole : userid,roleid,username,password (this design help you can assign more than one role to a user)
tblrole, tbrules(your Access Controls for example pages)
tblRulesInRole : roleid , ruleid,Editable,Viewable,printable,Deletable
For Implement Access Control in every request and response ,you should Create HttpModule......
I am using forms authentication and need to get a list of users that have a certain role and have a certain value in a certain profile property. The way I am doing this is to call Membership.GetAllUsers and then looping through them and checking the roles and profile. Is there a better way to do this in 1 call so that I don't have to get all users back and iterate?
Thanks,
Sachin
You may use GetUsersInRole() method.
string []users=System.Web.Security.Roles.GetUsersInRole("role");
You might want to replace Membership.GetAllUsers with Roles.GetUsersInRole(string roleName) - at least you'll have less entries to check for your custom field value.
In my master page I have:
MembershipUser thisUser = Membership.GetUser();
loggedInUserID = thisUser.ProviderUserKey.ToString();
thisUser gives me access to all the fields in aspnet_Membership.
I want a new field, isSubscribed for each user. I can use an SQL query to fetch the value fine, but I want to know if there is someway to modify the membershipuser object so it retrieves this value as well, so it is accessible from:
thisUser.isSubscribed.ToString();
Thanks for any help!
you will need to add the field to the Profile Provider
A description of the Profile provider can be found here.
http://msdn.microsoft.com/en-us/library/2y3fs9xs.aspx
here is an excerpt from the article
"The ASP.NET profile feature associates information with an individual user and stores the information in a persistent format. Profiles allow you to manage user information without requiring you to create and maintain your own database. In addition, the ASP.NET profile feature makes the user information available using a strongly typed API that you can access from anywhere in your application."
Membership is for identification and authentication. It is not good practice to hack your security for the sake of a meta property.
As mentioned, Profile is the proper place to store meta data and this would obviate the need for a custom MembershipUser.
If you need sql query access to the data use the SqlTableProvider
Si Robinson gave a good answer for storing additional meta data against users without having to change the underlying schema but if you already have data stored about this user in your custom database schema, that won't quite work out.
The solution I have used is to implement my own membership provider:
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
And then you can implement your own MembershipUser which exposes the IsSubscribed property.
This works fine with the Membership process within ASP.NET such as the login components. All you need to do is cast the object returned by GetUser() to your custom implementation and you are set!
You could use roles for this and assign users to a Subscriber role. Such as:
Roles.AddUserToRole("Bob", "Subscriber");
You're gonna have a real un-fun time querying by profile fields. With a role you will be able to enumerate users with:
Roles.GetUsersInRoles("Subscriber");
And you'll be able to add these roles to Web.Config files to control which parts of the site only Subscribers can see. Possibly better than wrapping content with a conditional based on a profile field.
I'm making a security permission system for a Dynamic Data site based on the article Securing Dynamic Data Preview 4 Refresh. The system contains an additional permission kind: "deny an operation for a record/field if a record is not owned by an user".
If an user can read only own objects, we need to have an always enabled filter in List and check permissions in Details. If an user can write only own objects, we need to check permissions in Edit and Delete, remove "Edit/Delete" links from some rows in List, make "User" field readonly and provide its value in Insert. I didn't think about column-level permissions of this kind yet.
So, the main problem, as I see at this moment: too many places to place the same checks (I didn't even think of malicious user crafting POST data). Also I couldn't make make a field in Insert at the same readonly and having a value which is displayed and saved to DB (I don't want to place that in the model partial classes because I think that there are already too many places that need to be edited to implement this functionality).
Is there a single place to deny a read or write operation with an object depending on the object value?
How can I provide a default value to the field, so that it will be shown on the Insert page, inserted to the DB and couldn't be changed by the user before inserting?
The following assumes you're using LINQ to SQL.
Is there a single place to deny a read
or write operation with an object
depending on the object value?
Reads
I know of no simpler way to restrict reads than to add a filter to all the relevant LinqDataSource controls. If you are able to implement your filter generally, you can write one QueryCreated handler, then add a single line registering your custom handler to all the page templates.
Writes
In the Dynamic Data metadata, add an OnValidate partial method to all the relevant tables. If the current user is not allowed to ChangeAction the given record, throw an exception. You will still have to update all the page templates to hide UI elements that the user does not have access to, but at least you can rest assured that the worst that could happen in some unexpected case is that the user sees an error page.
How can I provide a default value to
the field, so that it will be shown on
the Insert page, inserted to the DB
and couldn't be changed by the user
before inserting?
Perhaps look at some combination of adding an OnCreated and OnValidate partial methods. See also: this answer.