search

AnantLabs / codesmith

Automatically exported from code.google.com/p/codesmith
1 stars 0 forks source link

CSLA Security implementation - Setting up security incorrect in CSLA 3.8 generation #611

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Run VB code generation for objects for CSLA 3.8x
2. Review Authorization rules implementation.

What is the expected output? What do you see instead?

http://www.google.com/codesearch#9KVrtTKxCP0/trunk/Templates/Frameworks/Csla/Vis
ualBasic/Common/AuthorizationRules.cst

Line 26 should be
Private Shared Sub AddObjectAuthorizationRules()

as 
http://www.lhotka.net/cslacvs/viewvc.cgi/core/branches/V3-8-x/cslacs/Csla/Securi
ty/ObjectAuthorizationRules.cs?r1=2563&r2=4246&diff_format=s 

indicates that calls to object security implicitly require methods to 
"AddObjectAuthorizationRules" to correctly configure the cache of security 
roles in a software solution!!!!

Calls like 
Csla.Security.AuthorizationRules.CanGetObject(GetType(MyApp.Library.VipSecureObj
ect)) 
will not correctly load the security roles as a result.

What version of the product are you using?
Latest everything.

Original issue reported on code.google.com by jamie.cl...@jenasysdesign.com.au on 25 Nov 2011 at 1:09

GoogleCodeExporter commented 9 years ago 
Further testing shows the correct implementation of BusinessObjects should be.

Private Shared Sub AddObjectAuthorizationRules()
            ''More information on these rules can be found here (http://www.devx.com/codemag/Article/40663/1763/page/2).

            Dim canWrite As String() = {"Edit"}
            Dim canRead As String() = {"Read"}
            Dim canDelete AS String = {"Delete"}
            Dim admin As String() = {"Admin"}

            AuthorizationRules.AllowCreate(GetType(CSLA.BusinessObject), canWrite)
            AuthorizationRules.AllowDelete(GetType(CSLA.BusinessObject), canDelete)
            AuthorizationRules.AllowEdit(GetType(CSLA.BusinessObject), canWrite)
            AuthorizationRules.AllowGet(GetType(CSLA.BusinessObject), canRead)
        End Sub

        Protected Overrides Sub AddAuthorizationRules()
            MyBase.AddAuthorizationRules()

            Dim canWrite As String() = {"Edit"}
            Dim canRead As String() = {"Read"}           

            'AuthorizationRules.AllowRead(_identityProperty, canRead)
 End Sub

Collections only need the 
Private Shared Sub AddObjectAuthorizationRules() method security options.

Original comment by jamie.cl...@jenasysdesign.com.au on 25 Nov 2011 at 1:31

GoogleCodeExporter commented 9 years ago 
Hello,

Can you please comment on the following :).

1) The implementation is correct for both CSLA 4.x and 3.8 when it comes to the 
method names.
2). The only change needed for AuthoizationRules is to change the modifier from 
protected to private.
3) That the MyBase.AddAuthorizationRules() is 100% needed. From my past 
experience, this throws an exception. (I think it still does in 3.8 but haven't 
looked).

Original comment by bniemyjski on 28 Nov 2011 at 2:32

GoogleCodeExporter commented 9 years ago 
Here is a screen shot of the changes required to all code in the "Entity" 
folder classes.
The AddObjectAuthorizationRules method name is implicitly required to retrieve 
security outside of the business object, for things like menu item enabling.
Example (VB).

SearchToolStripMenuItem.Visible = 
Csla.Security.AuthorizationRules.CanGetObject(GetType(BL.MyVIPObject))

This code would fail if AuthorizationRules.AllowGet wasn't in a method called 
AddObjectAuthorizationRules. If you search the CSLA source code for 
"AddObjectAuthorizationRules" you can see the implicit method name hard coded 
into the source code.

Original comment by jamie.cl...@jenasysdesign.com.au on 19 Dec 2011 at 6:26

Attachments:

GoogleCodeExporter commented 9 years ago 
The 3.8 rules override the AddAuthorizationRules BusinessBase method as shown 
here 
(http://www.lhotka.net/cslacvs/viewvc.cgi/core/branches/V3-8-x/cslacs/Csla/Core/
BusinessBase.cs?diff_format=s&revision=4725&view=markup). I believe this is the 
correct behavior. I can see what your saying for the auth rules that are 
invoked via reflection...

Original comment by bniemyjski on 16 Jan 2012 at 9:09

GoogleCodeExporter commented 9 years ago 
Please update this ticket if this isn't the proper implementation.

Original comment by bniemyjski on 6 Mar 2012 at 9:19

GoogleCodeExporter commented 9 years ago 
I have more information around the Authorization rules problem now.

If you want to have field level authorization rules, the current implementation 
causes a compile error if you try and use them. (See screenshot with roll 
over). To confirm this just uncomment some of the existing code generated for 
property Authorization to confirm.

To ensure that you can use Field level authorization rule, you need to 
implement the second pattern. You will notice that the canWrite, canRead and 
admin strings may need organised differently.

Original comment by jamie.cl...@jenasysdesign.com.au on 21 Mar 2012 at 6:09

Attachments:

GoogleCodeExporter commented 9 years ago 
You will also notice, once this code is separated, that the intellisense is 
completely different in the two methods (for AuthorizationRules.SPACE). Glad I 
hit this because I didn't realise there was an 
AuthorizationRules.AllowExecute("MethodName",Roles()) option, which I really 
needed for one of my business objects.

Original comment by jamie.cl...@jenasysdesign.com.au on 21 Mar 2012 at 6:15

GoogleCodeExporter commented 9 years ago 
Attached is an un-tested patch.

Original comment by jamie.cl...@jenasysdesign.com.au on 21 Mar 2012 at 6:22

Attachments: