This is driving me nuts, but I can't navigate away from a bound masked textbox to any of the other controls on a form. I have the masked textbox bound to a BindingSource which, in turn, is bound to one of my business objects. The problem seems to occur after the user clicks on the cmdNewCategory button to create a new category record. I'm not sure the problem is caused by the cmdNewCategory_Click function or not, but the code for it is as follows:
private void cmdNewCategory_Click(object sender, EventArgs e)
{
catPosition = bindingSourceCategories.Position;
categories.AddNew();
bindingSourceCategories.DataSource = categories;
bindingSourceCategories.MoveLast();
navigatorCategories.BindingSource = bindingSourceCategories;
categoryCodeMaskedTextBox.Mask = "\\" + deptCode + ">A";
categoryCodeMaskedTextBox.ReadOnly = false;
categoryCodeMaskedTextBox.Focus();
categoryDescTextBox.ReadOnly = false;
cmdSaveCategory.Enabled = true;
cmdCancelCategory.Enabled = true;
cmdNewCategory.Enabled = false;
cmdDeleteCategory.Enabled = false;
}
Any help would be greatly appreciated.
Allen Anderson
William, I tried to find a reference to your DateTimePicker issue but couldn't locate it. One thing I've just noticed is that a System.Security.SecurityException is being thrown as soon as I try to navigate away from the maskedtextbox.
William:
I encountered the similar issue in the past where I bind a DateTimePicker control's Value property. See if this helps.Regards,William
I've found the problem; AllowWrite(string propertyName, params string[] roles) throws the error because the code generator I'm using to generate my Category class produces the following line in the AddAuthorizationRoles:
AuthorizationRules.AllowWrite("CategoryCode", "CategoryWriteGroup");
and there's nothing in the CategoryWriteGroup array. Where (or how) do I insert the allowed roles into the CategoryWriteGroup array?
Albruan,
I think you are misinterpreting the AllowWrite syntax. The second parameter to the AllowWrite method is an array of role names that are allowed to write to the property specified in propertyName (the first parameter). In this case, "CategoryWriteGroup" is the name of a role that would contain the users who were allowed to write to this property. Depending on the type of security that you are using you'll need to appropriately create a "CategoryWriteGroup" role (you can name it whatever you want, as long as you stay in sync with your generator). Once you have the role created, you'll need to add the appropriate users to this role.
Dustin
I understand that, that's why I asked "Where (or how) do I insert the allowed roles into the CategoryWriteGroup array?" Do I create it in my override of the Security.Identity class or should the array be created elsewhere? I'm assuming I will also have to create similar arrays for the rest of my business objects that write similar properties to my data store. Am I correct in assuming this?
Allen B. Anderson
Albruan,
I think you are misinterpreting the AllowWrite syntax. The second parameter to the AllowWrite method is an array of role names that are allowed to write to the property specified in propertyName (the first parameter). In this case, "CategoryWriteGroup" is the name of a role that would contain the users who were allowed to write to this property. Depending on the type of security that you are using you'll need to appropriately create a "CategoryWriteGroup" role (you can name it whatever you want, as long as you stay in sync with your generator). Once you have the role created, you'll need to add the appropriate users to this role.
Dustin
Allen,
Sorry it took me so long to reply. I've been out of the office the last couple of days. I'm no expert on security in CSLA, but here are a few things that should help you get started. First off, do you plan on using Windows integrated authentication, or custom CSLA authentication? If you are in an environment where it makes sense to use Windows integrated security, you can take advantage of the WindowsIdentity and WindowsPrincipal classes in System.Security.Principal. This will allow you to use the users/roles already setup on the computer/domain. If you plan on going the custom CSLA authentication route, take a look at the ProjectTracker sample application that Rocky has provided with the framework. In the sample app he basically implements the IIdentity and IPrincipal interfaces in his own PTPrincipal and PTIdentity classes. Furthermore, he sets up a security database with a roles table and a users table. If you go this route, you'd enter say user1, user2, user3 as entries in your "user" table. Then you'd make entries in your "roles" table that link your users to certain roles. This would allow you to create a role named "CategoryWriteGroup" and add user1, user2, and user3 to that role. Then you could use the AllowWrite command as follows:
AllowWrite("category","CategoryWriteGroup")
Once you have authenticated the user using the Pricipal and Identity classes, be it the windows classes or your custom classes, the framework should be able to use this information in the AllowWrite implementation to determine if the user is in the allowed role.
Dustin
Copyright (c) Marimer LLC