|
I am trying to lock down all DataPortal Actions on my business objects by default. I created a base BO thati inherit from: Yet I am finding that randomly when I call SaveAsync() on my BO, it will allow it to save even though I did not add the EditObject action for that BO to my public registry. I am calling SaveAsync() from a Blazor WASM component and the DataPortal is running on the server. Usually when it does allow it to save it, it is on the first try after starting the debugger, but it is not always reproducible. When it does allow the save, I do not see any of the logging from the Execute on ConventionPermissionRule. Can anyone shed some light on what I am doing wrong and if there is a better way to handle this. Thank you |
Replies: 6 comments 1 reply
|
What version of Csla are you using? I am wondering if this is a version that still contains the Blazor authorization bugs |
|
Latest version. 10.1
Thanks
…On Thu, Aug 6, 2026, 6:19 AM TheCakeMonster ***@***.***> wrote:
What version of Csla are you using? I am wondering if this is a version
that still contains the Blazor authorization bugs
—
Reply to this email directly, view it on GitHub
<#4877?email_source=notifications&email_token=AJLAXO7DHE4BAKQQQU2TRUD5IRLTVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGE4TGOJTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17919393>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJLAXOYTTOOE34BFWT2TFI35IRLTVAVCNFSNUABGKJSXA33TNF2G64TZHM4DAOBVG42DSO2ENFZWG5LTONUW63R3GEYDKNJUGM3THILWAI>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AJLAXO6U5BJMWAR265JL5ET5IRLTVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGE4TGOJTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM>
and Android
<https://github.com/notifications/mobile/android/AJLAXOZVB4ECTMBQERKPHY35IRLTVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGE4TGOJTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
OK, it's not beijg caused by what I thought then. I'm not really sure why it's failing. However, as shown by your own code, auth rules are more about the initiation of operations - starting an edit in your case - than running the data portal operation itself. It might not be the best way to do what you want. There are points of extensibility for validation and authorisation in Csla, and using the latter feels like the best approach for safeguarding the server-side operations themselves. To do this, you would create a class implementing IAuthorizeDataPortal - ideally extending ActiveAuthorizer - and put your logic there. This doesn't really answer your question entirely. I wonder if it might be a bug in the one bit of code you didn't show - PublicSecurityRegistry - but that wouldn't explain why the debugging information doesn't show up, so I don't think that's really it. |
|
@TheCakeMonster , what do you mean by extending ActiveAuthorizer? It does not seem to be virtual. I went away from placing adding the rule on the base class to source generating the rule, and I am no longer using the PublicSecurityRegistry to make actions public. I am using an attribute on the class to tell the source generator not to include the action if it is public. This did not fix my issue. It still allows through actions that should be locked randomly. For completeness, this is what the PublicSecurityRegistry looked like With the source gen I add an attribute to the class: And that will cause the source gen to leave out Create and Get: |
|
I implemented @TheCakeMonster solution of extending ActiveAuthorizer and had the exact same random issue. After adding a whole lot of debugging and feeding it to AI, the mystery was solved, It had to do with the Blazor lifecycle and where the code was running. Thank you @TheCakeMonster for your assistance. Extending ActiveAuthorizer is definitely a cleaner solution. |
|
I just inherited from and declared the interface. That seemed to work
Thanks for your help. |
I implemented @TheCakeMonster solution of extending ActiveAuthorizer and had the exact same random issue. After adding a whole lot of debugging and feeding it to AI, the mystery was solved, It had to do with the Blazor lifecycle and where the code was running.
Thank you @TheCakeMonster for your assistance. Extending ActiveAuthorizer is definitely a cleaner solution.