Site Alias with Canonical setting seems to be replacing the domain name with canonical form also in querystring parameters

[ahawes-clarity]

I just had an issue where a URL was inexplicably being rewritten.

The URL took the form of:
http://host.com/page?email=user@host.com

The site had one site alias of "www.host.com" and it was set as primary and the "Site Alias Mapping Mode" was set to "Canonical".

However, when my custom module code would read the value of the email parameter from the querystring of the above request I would get an email value of "user@www.host.com".

var email = Request.QueryString["email"];

As I understand, the site alias settings would typically rewrite requests for "host.com" to "www.host.com".

I update the "Site Alias Mapping Mode" to redirect and the problem went away.

My guess was that the code responsible for handling "Canonical" site alias mapping is just doing a simple replace which was replacing the "host.com" not just in the base URL but also incorrectly in the querystring.

I tried to find the issue in the DNN source and I think I might have found at least one instance of the issue in Default.aspx.cs.

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[ahawes-clarity]

Just commenting to keep this bug active.

[stale]

We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically.
If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!

[ahawes-clarity]

Just commenting to keep this bug active.

[valadas]

@ahawes-clarity since you appear to have found the problem, submitting a pull request would be much more efficient than keeping commenting on this stale issue.

[ahawes-clarity]

@valadas, I understand your point however, I don't have the time and without knowledge of the whole platform I can't be sure my solution is correct.

[valadas]

I am assuming you found this by putting a breakpoint there and you are comfortable enough to see what is happening in there. My guess is that you could simply split the string on the querystring start character and make that replacement happen only on the first part of the URL. If you submit a PR with such change, reviewers will point out if anything is not right and we can get this moving.

[ahawes-clarity]

Thanks for your feedback. I will see if I have time. I haven't contributed previously so we will see how it goes.

[ahawes-clarity]

I just reviewed the process and requirements to contribute and I just don't have the time. Most of my work time needs to be charged to a client and I can't justify client time to fix a DNN bug.

I had assumed that taking the time to find and pin-point the problem would be sufficient to see that the bug was addressed.

In any case, that is all I can do at the moment.

[valadas]

You do understand that contributors to fix such bugs also do it free and take some time off their real paid work to provide a free platform...

[david-poindexter]

@ahawes-clarity I would highly recommend you consider billing your client for the fix they need in the platform. This is what we do all the time. And we are transparent about it to them. :)

[david-poindexter]

Oh, and if you don't have the time, this is a perfect use case for GitHub Sponsors. You could bill your client, use that to sponsor a community member that is willing to help, and then it is a win-win-win-win.