Pages MetaData Editing Mode Support #29
Conversation
…d EditScripts TagHelper
…d in editing config request. Updated related tests
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| { | ||
| logger.LogDebug("Processing valid Pages Render request"); | ||
| PagesRenderArgs args = ParseQueryStringArgs(Request); | ||
| return Redirect($"{args.Route}?mode={args.Mode}&sc_itemid={args.ItemId}&sc_version={args.Version}&sc_lang={args.Language}&sc_site={args.Site}&sc_layoutKind={args.LayoutKind}&secret={args.EditingSecret}&tenant_id={args.TenantId}&route={args.Route}"); |
Check warning
Code scanning / CodeQL
URL redirection from remote source Medium
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix
AI 10 days ago
To fix the problem, we need to validate the user input before using it in the URL redirect. One way to do this is to maintain a list of authorized routes and ensure that the user-provided route is in this list before performing the redirection. Alternatively, we can check that the target URL does not redirect to a different host by ensuring that the URL is either relative or on a known good host.
In this case, we will implement a validation method that checks if the route is in a predefined list of valid routes. This method will be called before performing the redirection.
| @@ -52,3 +52,7 @@ | ||
| PagesRenderArgs args = ParseQueryStringArgs(Request); | ||
| return Redirect($"{args.Route}?mode={args.Mode}&sc_itemid={args.ItemId}&sc_version={args.Version}&sc_lang={args.Language}&sc_site={args.Site}&sc_layoutKind={args.LayoutKind}&secret={args.EditingSecret}&tenant_id={args.TenantId}&route={args.Route}"); | ||
| if (IsValidRoute(args.Route)) | ||
| { | ||
| return Redirect($"{args.Route}?mode={args.Mode}&sc_itemid={args.ItemId}&sc_version={args.Version}&sc_lang={args.Language}&sc_site={args.Site}&sc_layoutKind={args.LayoutKind}&secret={args.EditingSecret}&tenant_id={args.TenantId}&route={args.Route}"); | ||
| } | ||
| return BadRequest("Invalid route."); | ||
| } | ||
| @@ -73,2 +77,9 @@ | ||
| } | ||
|
|
||
| private bool IsValidRoute(string route) | ||
| { | ||
| // Define a list of valid routes | ||
| var validRoutes = new List<string> { "/home", "/about", "/contact" }; | ||
| return validRoutes.Contains(route); | ||
| } | ||
|
|
…DictionaryService
…th customisable HeaderCollection instead
…ons as its not supported by MetaData Editing
|
I have tried this and it is working (almost) as expected 👍 When I have the SXA LinkList rendering inserted on a page then editing that page in Pages is failing: I think the reason is that this rendering has an Integrated GraphQL query specified in Sitecore. Layout response with ContentResolvers are properly handled, because it is rendered as an array. When parsing the layout in CustomContrentFieldKey and hereby handled in However this result from the Integrated Query is not going into this code path but is ending up as a standard field with the serialization error shown. I completely acknowledge that this is something we need to handle in the ASP.NET SDK because we are using model binding with (real) strong types while the node based SDK is (more or less) just ignoring this difference 😄 |
Good catch @jballe, I'd forgotten about the iGQL in use on that control. I've updated the error handling in the I think this will work for now, and we can say that anything implemented with a custom Rendering Contents Resolvers, or with iGQL that changes the structure of the data returned will no longer be editable. We can then have a look at how to better handle deserialisation of these custom types, as the strong typing model in dotnet will make this more challenging than in node as you mentioned! |
|
Thank you @robearlam that was really fast! I have tried it and it is now working with those changes. I have two other comments - with the risk of delaying the PR (and especially when I have been poking @IvanLieckens it might not be the best timing) - so let me just give the input and then you can decide if it should actually be part of this PR or a future improvement - or maybe even something unrelated to this... When using metadata editing in Pages there is a request to config endpoint, implemented in the PagesSetupController. I had to make two changes here to get rid of console/CORS errors, so I have added More important: In this example I have moved the Promo view to a subfolder and changed the view name with a registration like this: renderingEngineOptions.AddModelBoundView<Promo>("Promo", "HeadlessExperienceAccelerator/Promo")
For ViewComponents it is actually worse, the extension method to register the view component But the method signature is changed to have a locator as a second paramter, so we end up with a registration with an empty componentName I can see you have had a bit back and forth on how this actually should be so it was probably not changed everywhere. But, from what I see, I think we need to store the actual component name that is used to build the predicate so that it can be exposed in the config endpoint. Right now I think there is a bit confusion on what is the component name used in the layout response and what is the name used to render the component. |
This PR adds support for Pages MetaData Editing.
Description / Motivation
Testing
Terms
Closes #17