Dnn.Platform
Dnn.Platform copied to clipboard
dnnsoftware
Page gets redirected, if the page URL is the same as portal alias with a different domain
Description of bug
If the page name is the same as the portal name in a different domain, the page can't be accessed since it redirects to the other portal when tried to be accessed.
Steps to reproduce
- Let's say the root portal has a page with URL "922e.dnndev.me/dallas" (notice that the site has a subdomain of "922e" and a postfix of "dallas")
- Admin created a new portal with "dnndev.me/dallas" url
- Try to access the "dallas" page of the root portal from Step 1.
Current behavior
The request gets redirected to the new portal's home page from Step 2.
Expected behavior
The "dallas" page of the main site from Step 1 (922e.dnndev.me/dallas) should be opened.
Screenshots
Reproduction video: https://drive.google.com/file/d/1syAoLyUFDKJumYP5ImqX7bkTJeaXP1y1/view
Affected version
- [X] 10.00.00 alpha build
- [ ] 09.09.00 latest supported release
Affected browser
- [x] Chrome
- [ ] Firefox
- [ ] Safari
- [ ] Internet Explorer 11
- [ ] Microsoft Edge (Classic)
- [ ] Microsoft Edge Chromium
the problem seems to be in the routine to create a sub-website, which needs to check for an existing page path and should prevent the site to be created in this case (AFAIK creating a page URL doesn't work, if there already is a sub-website with same address.)
btw. I disagree that a page URL should override a sub-website with same URL. Is there any specific use case you are having in mind?
Github applied a formatting to an important text there and I fixed it and it might have created this confusion. I edited the followings:
To explain the issue in more detail: If there is a site with "test" name for example, you can't have a page named as "test" (in the same domain) and there is already a check for that. However, the problem occurs only when the portal gets created on a different domain. Because the following URLs should return different pages:
- domain.dnndev.me/test1 (refers to page)
- dnndev.me/test1 (refers to a site's home page)
You can check my PR from https://github.com/dnnsoftware/Dnn.Platform/pull/4670 btw.
there is a problem caused by the redirect for sub-portals. If I remember correctly, if you create a sub-website "domain.dnndev.me/test1", a folder is created in the root folder (/test1) with a redirecting default.aspx. This should be accessible with higher priority than a page with same name in the parent site. However, UI of DNN should try to avoid sub-website and page with same path to be created.
Asking for additional confirmations that this can't be implemented before closing the issue. I updated the reproduction steps to make it easier to understand the issue.
I agree that this is a bug that should be fixed. However, the fix cannot be to blindly accept pages over aliases. In this case, there is no ambiguity, so the code that selects dnndev.me/dallas has a bug (presumably because it isn't considering the full domain).
If the issue is the creation of the subdirectory, as @sleupold suggests, we may need to consider if that subdirectory creation is even still required (AFAIK it was in place before we had ubiquitous handling for extensionless URLs).
So the fix would need to be either in the subdirectory creation or in the code that checks for an alias match (or both).
In the case where there is ambiguity (e.g. an alias example.com with a page Dallas 🆚 an alias example.com/dallas), I would say we still want the alias to take precedence over the page.
Hi @bdukes . The issue is not related to subdirectory creation in any way.
In your last paragraph you stated that for the ambiguity cases, the alias should take precedence. However, that case is not possible in the first place because if you have a site with example.com/dallas URL, you can't have a page named "dallas" in the same domain because there is already a validation for that:
and vice versa (creating the page first and then the site):
The problem with the code was that it wasn't checking the pages at all and it was returning directly in case there is a possible match in the alias and my code fixes that. I can provide detailed debugging pictures etc. if you require, just let me know.
The problem with the code was that it wasn't checking the pages at all and it was returning directly in case there is a possible match in the alias and my code fixes that. I can provide detailed debugging pictures etc. if you require, just let me know.
Team, let's restore the discussion on this to either close or move forward
As far as I can see, PR #4670 does contain some discussion. Did you check out feedback from @bdukes ?
yes, the conversation there ended by redirecting the discussion here, and feedback from Brian was commented
Hey team, could you please check this individually or discuss the impact and solution on then next TAG meeting?
@v-karbovnichy We discussed this today during the approvers meeting, we will review this with a proposed recommended path and comment back after our next meeting.
