Links broken due to port being added to the URL
Hi,
For some reason, it seems the port is added to some URLs, while it shouldn't be.
I have no idea why (some configuration problem somewhere?). This is causing issues for us (these URLs do not work because of the addition of the port), especially in 2 specific cases:
1- We have a custom backend login page (to add https), which contains:
<sf:LoginForm AllowSelectMembershipProvider="true" ID="LoginFormControl" RememberMeSet="true" ShowChangePasswordLink="false" ShowForgotPasswordLink="false" ShowHelpLink="false" ShowRegisterUserLink="false" DisplayRememberMe="true" DestinationPageUrl="~/Sitefinity" runat="server" />Hello Thomas,
There is a useful setting called "Site URL Settings" which allows you to change the absolute URLs generated by Sitefinity. It can be used when your installation is behind a specific port, have some internal redirection or use proxy. We have discussed a similar problem in this thread, so I can recommend it for you to review it.
Greetings,
Victor Velev
the Telerik team
Hi Victor,
Thanks for the tip. This seems to have fixed the second issue, but not the first one. Could be due to the HTTPS -> HTTP trip. Can you think of a solution?
If everything fails, I guess I could hard code an absolute DestinationPageUrl value, but I'd like to avoid that.
Hello Thomas,
It looks like some issue when calling Page.Response.Redirect (which we call with the parameter that you specify in DestinationPageUrl). I found the following article in StackOverflow:
http://stackoverflow.com/questions/853513/how-to-overwrite-response-redirect-to-prevent-port-coming-with-it
It looks like you could add this attribute -
useFullyQualifiedRedirectUrl="false"Hi Lubomir,
Thanks for your time.
I also stumbled upon this info while looking for a solution. But that doesn't seem to be the problem, because the value of this attribute is false by default. Just in case, I double checked the value with this piece of code:
HttpRuntimeSection section = ConfigurationManager.GetSection("system.web/httpRuntime") as HttpRuntimeSection;bool test = section.UseFullyQualifiedRedirectUrl;Hi Thomas,
Could you search your config files and web.config for this pattern: ":448" - I'm not sure where it is saved. Also please check if you have some Global.asax code that might perform a redirect.
Greetings,Hi Lubomir,
No sign of "448" in our solution. It must get that dynamically from the server somehow.
We do have a Global.asax, but it doesn't perform a redirect. It add routes to enable the custom login page.
I'll try setting the DestinationPageUrl property to an absolute URL next time I deploy the app in production environment (which I won't be able to do before January the 9th).
Hello Thomas,
It would help if you gave us access to your backend so we could investigate. It is possible that you added some custom code or widgets that redirect to this hardcoded port but you forgot about them. You could search in the sf_control_properties table, in the "val" column for ":448" as well - if there are any custom controls/widgets with this value they should be stored there.
All the best,Hi Lubomir,
No, the port is not hardcoded in any way in the app. Actually, the same app works fine on other servers, so it specific to our production servers that have a more complex configuration.
I'll be able to tell you next week if my workaround works or not.
With all that said, it seems the port being added to the URL was a Sitefinity bug after all.
www.telerik.com/.../pits.aspx
I'll upgrade to SF 5.0 and see...
Hi Thomas,
Please make sure to verify the behaviour on your end, using our official 5.0 release as the bug is marked as resolved.
Regards,
Victor Velev
the Telerik team