When opening ImageVault from EpiServer the error "too many redirects ..." is displayed in the browser.
ImageVault 5.14 or later
ImageVault.EpiServer.UI earlier than 11.7
You can fix the issue in two different ways
- Upgrade ImageVault.EPiServer.UI to version 11.7 or later
- Change targetFramework attribute in httpRuntime (/configuration/system.web/httpRuntime) to at least 4.5 (see notes below)
Technical info for the interested
When opening ImageVault to insert images in Episerver, we need to use an iframe. Some federated authentication mechanisms (like Azure-AD) prohibit iframes to accommodate a user login. To be sure that you are authenticated in ImageVault and can browse the images in the iframe, we first open ImageVault and when the user is logged in, we redirect the user back to the iframe page.
The URL to the iframe page contains parameters:
This URL is sent to ImageVault as a parameter itself and since it contains parameters, the redirect URL is encoded to not mix it's parameters (param1, param2) into the parameters to the ImageVault URL.
Problem is that we load all these parameters as a Uri object and uses the ToString() method to write the URL to the browser.
Uri.ToString() decodes many of the characters in the URI and behaves differently between dot net framework versions. An investigation for the behavior is described in the blog article Uri.ToString() automatically decodes Url encoded characters.
In this particular case, the combination of the URL above, Uri.ToString() and dot net framework 4.0 produces the following output.
This will remove the param2 from the ivui.aspx URL and move it to the imagevault URL, which in this case results in the "too many redirects" error.
Upgrade ImageVault.EPiServer.UI to 11.7 or later
In ImageVault.EPiServer.UI we have fixed the issue by NOT using Uri.ToString(). As described in the blog article above, the Uri.AbsoluteUri or Uri.OriginalString will not decode the characters. This fix is present in ImageVault.EPiServer.UI 11.7 or later
Setting targetFramework to 4.5 or later
You can also use a newer framework than the default 4.0 by modifying the web.config and setting the targetFramework attribute in the /configuration/system.web/httpRuntime element to at least 4.5, by that the &=? characters will not be decoded and the system will work.
- Beware that the httpRuntime can be present in many location nodes in the web.config but you need to set it at the global level (/configuration/system.web/httpRuntime).
- The targetFramework is also present in the compilation node (/configuration/system.web/compilation) but this only effect which framework is used when runtime compilation is needed, not the action framework version used when running the code.