Fix blog permissions viewstate - #225
Conversation
Prevent restoring dynamically generated permission-grid child ViewState after Blog permission changes.
## Summary This pull request fixes a ViewState exception that occurs when editing Blog settings after Blog permissions have been changed. The issue is caused by `BlogPermissionsGrid` saving and restoring the ViewState of dynamically generated child controls. After permission changes, the generated control tree can differ between requests, causing ASP.NET to throw: ``` Failed to load viewstate. The control tree into which viewstate is being loaded must match the control tree that was used to save viewstate during the previous request. ``` ## Root cause `BlogPermissionsGrid` persisted the base child-control ViewState: ```csharp allStates[0] = base.SaveViewState(); ``` and later restored it using: ```csharp base.LoadViewState(myState[0]); ``` Because the permissions grid is dynamically generated, the child-control structure can legitimately change after permission updates, making the stored ViewState invalid. ## Fix - Do not persist dynamically generated child-control ViewState. - Continue to persist: - Blog ID - Current User ID - Blog permission collection - Rebuild the permissions grid on each request. ## Testing Verified successfully on DNN Platform 10.3.2 / .NET Framework 4.8. Tested by: - Editing existing Blogs - Creating a second Blog - Repeated Blog permission changes - Updating Blog settings - Creating posts - Editing posts - Uploading images to posts The fix was also validated on a production site running the unmodified Blog 6.7.1 release by replacing only `DotNetNuke.Modules.Blog.Core.dll`.
…hanges Tested successfully on DNN Platform 10.3.2 / .NET Framework 4.8 with SQL Server. Verified by: editing existing Blogs creating a second Blog repeated permission changes changing Blog settings creating and editing posts uploading images validating on a production site running the stock Blog 6.7.1 release
|
I hope this is done right and the fix helps. |
|
@Forro-54 any reason for closing the PR? |
|
Sorry my bad. |
|
Again, Sorry my bad. Kind Regards |
valadas
left a comment
There was a problem hiding this comment.
This looks good to me and I tested both the issue and the fix.
@donker are you good with this? The base does not have LoadViewState other than the default webforms control one, so that looks safe to me and I did not notice issues.
Fixes #224
Description of PR...
Changes made
PR Template Checklist
Please mark which issue is solved
Close #