A critical vulnerability was discovered in React Server Components (Next.js). Our systems remain protected but we advise to update packages to newest version. Learn More.
Hi Dileep,
I have used Uri class constructor to create a qualified URL, try this way.
var url= _urlResolver.GetUrl(contentLink);
var qualifiedUrl= new Uri(SiteDefinition.Current.SiteUrl, url);Hi,
The 'ForceCanonical = true' setting does not guarantee that you always get an absolute Url. Even with this setting set to true, UrlResolver still depends on other settings (i.e: the hostname, the current site of content, etc ...) to decide which type of url (relative/absolute) should be returned. So maybe some hostname setting of your Integration environment differs from your Pre and Production environment.
If you want the API to always returns absolute Url, you can check if the _urlResolver.GetUrl() return a relative Url or not, then prepend the relative Url with the hostname.
Hello,
I have this issue which I can't figure out what it is:
Based on EpiServer articles I am using a CustomContentModelMapper and overriding below method to get fully qualified urls in Content api resonse.
{
string resolvedUrl;
if (_urlResolver == null)
{
resolvedUrl = _urlResolverService.ResolveUrl(contentLink, language);
}
else
{
resolvedUrl = _urlResolver.GetUrl(contentLink, language, new UrlResolverArguments()
{
ContextMode = ContextMode.Default,
ForceCanonical = true
});
}
return string.IsNullOrEmpty(resolvedUrl) ? null : UriSupport.AbsoluteUrlBySettings(resolvedUrl);
}
However for some reason, in my integration enviroment, I see some urls (like image url etc) still coming as reference url and not fully qualified. Pre production and Production environments are working fine as expected.
I am not sure what is it that is causing issue in integration environment. Any thoughts what I could check. Also is there a way to ignore the port number from the fully qualified url.