I’m having an issue with the url rewriter.
When in the experience manager a token is passed to our front-end site and the url rewriter is activated (for example /articles/03/2022/testArticle?token=blabla to /articles/testArticle?token=blabla), the token is stripped away with the url rewriter. If I use any other query param like tokentest, then the token is NOT stripped away. Is this intentional? How can I disable this?
I have enabled Append Query String.
If I go to content and the document and click on view on site, it does work. Our users can not edit pages directly now through the experience manager. It seems that the View → Website button already applies the url rewriter url (so you automatically go to /articles/testArticle). I have no clue why this happens.
Can anyone explain to me how I can fix this?
We used a react frontend, I have a feeling it has to due with the SPA SDK.
EDIT: I’m actually pretty sure the SPA SDK strips it away, but I don’t know why
And for the issue with the experience manager, we have a version of a HstLinkProcessorTemplate. The doPostProcess is called when you click on View → Website button but not on the sitemap when you click the item you want. That’s another issue I guess
I will attempt to clarify as best as I can, as what you described definitely mixes many different topics.
The token parameter is indeed a reserved one by the SPA SDK as the SDK passes the authorisation token when in preview in order to retrieve preview data.
Now the tricky part. What are you using the URL rewriter for? Is it the old deprecated SPA integration or for actual redirects?
Is this transformation /articles/03/2022/testArticle → /articles/testArticle happening via your custom HstLinkProcessorTemplate or do you actually have separate sitemap items that can render both scenarios and that’s why you use the URL rewriter?
The View->Website functionality will always select the shortest URL that this document is available from. So if in your case you have 2 different sitemaps items the one for /articles/testArticle will be preferred when you View the document. Hence also why your redirect doesn’t take place.
It is a bit hard to asses this part without knowing your exact implementation.
Yes, I have build a workaround that grabs the token from the Authorization header and appends the query parameter to the redirected url by checking for a 301,302 response from the resourceapi.
What do you mean by the old deprecated SPA integration?
The transformation is happening indeed through the HstLinkProcessorTemplate, and we don’t want to render both scenarios, we always want to redirect to the correct page.
There is only 1 sitemap item, and we know the sitemap works with the HstLinkProcessorTemplate because it’s removing the folder structure (03/2022 is removed, so you only see testArticle in the root of the articles folder/sitemap node). Only the correct URL is not called when you click on the item in the sitemap.
This is something that should be handled natively by the SDK.
This was the old way of setting up your SPA in preview. It was relying on the URL rewriter hence my question.
Could you please share your sitemap configuration, your folder structure (for articles) and your implementation of the HstLinkProcessorTemplate?