I have attached a zip file that contains the complete sample application solution for Visual Studio 2008 using C#. This was created using Strataframe version 1.7.0.2



I did not change any of the default code that was generated by the Strataframe template. I only added code for the "click" event of the button that I added to the form that was created by the template.



You should be able to unzip this file structure and then build, compile and run the application in the normal default debug mode of Visual Studio.



The zip file is named SecurityTest.zip

When you run this application you can log in as the integrated "Administrator" user and the application runs okay and clicking the "Security" button will open the run-time role-based security dialog to maintain the application users. If you log in as the integrated "Security Maintenance" user, the application will also run okay, but when you click on the "Security" button, you will get an "Access Denied" error message window and you can not run the security dialog to maintain the application user information. This is the problem that I am trying to resolve.

I tested your sample and I can see the same results, when log with the SecurityBasics.SecurityMaintenanceUserName then there is not access to the SecurityDialog. I don't have a solution for you, but I am sure the guys at SF will come up with something.

Edhy Rijo

I also tested and nothing obvious seems wrong. The permission on "Security Editor" for the security user is Deny (this is the key that the security dialog is using, according to source). However, when I look at the SecurityMaintenanceUser class, the GetPermission method is only going to return Grant for keys that start with Security_ by default. If you add a line to you code:







Now I'm not sure this will work for everything, but it does bring up the dialog with this.



Still this looks like a SF bug to me.

James,



First, there is no way for us to look at your security sample if you do not provide the data associated with your sample. Sending an application without the data will do no good. That being said, I am willing to bet that Greg's response to your issue is where your problem is. I believe that Greg has already given you the answer you need.



Let us know if you are still having trouble. Thanks.

One other thought here.  Be sure to check your vector security key:

So your distributed database will have to match what you have supplied in your application (above).  You set this in the project settings of your security project.

If these two things do not match, all of your users will be inaccessible and you will not be able to use them.  One easy way to tell is that your user icons will be different when you open the SecurityDialog from within your application.  If you do not have this setting correct, that will be short little blue guys and when you click the user, it will show an error in the right panel indicating that the user is not valid (or something along those lines).

Trent,

Adding the "Security Basics" patch code line did solve the problem.  I don't know what data for the application that you are referring to ... The use of the "integrated" Administrator and "integrated" Security Maintenance users should not require any "security" data to be set up for them ... There is no reference to them when you populate the security tables with user / role / permission / restriction information.

And I did verfify that the "security key" information matches ...

I think that maybe you still do not understand my problem ....  With the sample application that I posted, the integrated Administrator user works just fine ... no problems at all .... can access the Security Forms as expected .... BUT without adding the patch code line suggested in the previous post above,  the integrated Security Maintenance user can not access the Security Forms ....  You get an "Access Denied" message when you try to show the Security Forms dialog ....  After adding the patch code line, and not changing anything else ... the Security Maintenance user is able to access the Security Forms dialog as described in the documentation and samples ... just like the Administrator user can do before adding the patch code for the Security Maintenance user ...

There is something in the Strataframe code that will not let the integrated Security Maintenance User have access to the Security Forms without adding the patch code to an application.  This patch code has worked on every application that I have tested so far ....  WITHOUT the patch code ONLY the Administrator user can access the Security Forms ... BUT with the patch code BOTH integrated users can access the Security Forms ....

If you DO NOT add the patch code and use the integrated Administrator user to add Application Admins to the security table and give them "Administrative" rights when you set up the Application Admins, they ALSO can access the Security Forms without any problems ....  the only problem is with the integrated Security Maintenance user if you do not add the patch code suggested in the previous post ...

Does this information help explain the problem any better?

It does to me

Edhy Rijo

With very helpful assistance from Greg McGuffey, I have followed the flow of the code related to how the integrated Security Maintenance User is granted default permissions to the objects within a project.

Here is the short (and hopefully simplified) version of what I discovered with Greg's assistance:

1) In the Strataframe source code,  the "SecurityMaintenanceKeyPrefix" property is given a default value of "Security_"

2) In the Strataframe source code, the "Security Dialog" form is given a default "Security Key" of "Security Editor"

3) The integrated Maintenance Security User is granted security to objects based on the "SecurityMaintenanceKeyPrefix" value ... in this case "Security_"

This means when the integrated Maintenance Security User is logged into your application, any objects which are defined with a "Security Key" property value that STARTS WITH "Security_"  will be issued the "GRANT" permission for that object and allow the integrated Maintenance Security User access to that object

This is where the problem is created .... everything matches in the 2 character text strings through the word "Security" but the next text character is causing the Strataframe Security System to issue the "DENY" permission for the object (which is the Security Dialog form) because the prefix value is looking for an "_" (underscore character) as the next text character in the evaluation of the Security Key value for the object BUT the object (Security Dialog form) has a " " (space character) as the next text character and this DOES NOT MATCH !!!!!! 

Therefore, the integrated Security Maintenance User is denied access because of the mismatch between the space character and the underscore character.  Greg's patch code suggestion of adding a code line in the program.cs file to "redefine" the "SecurityMaintenanceKeyPrefix" to be "Security " ... works because this makes the " " (space character) after the word "Security" match in the prefix value and the object Security Key value.  As Greg also suggested, I have tested changing the "SecurityMaintenanceKeyPrefix" value to just "Securty" and this works just fine also BECAUSE the Strataframe Security System is matching the text characters from the "SecurityMaintenanceKeyPrefix" and the object "Security Key" for the length of the "SecurityMaintenanceKeyPrefix" text string.

A future fix for the Strataframe Source Code would be to change the default value for the "SecurityMainenanceKeyPrefix" or change the default value for the "Security Key" for the Security Dialog form  SO THAT they will both have the same "Starting" characters for the length of the "SecurityMaintenanceKeyPrefix" text string.

Trent, can this be done in a future release version ?????

A BIG Thanks goes to Greg McGuffey for helping me work through and understand this problem and the required solution.