Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PortalAlias Settings Not Correctly Observed #2841

Closed
11 of 13 tasks
WillStrohl opened this issue Jun 13, 2019 · 32 comments · Fixed by #3396 or #3832
Closed
11 of 13 tasks

PortalAlias Settings Not Correctly Observed #2841

WillStrohl opened this issue Jun 13, 2019 · 32 comments · Fixed by #3396 or #3832
Milestone

Comments

@WillStrohl
Copy link
Contributor

WillStrohl commented Jun 13, 2019

Description of bug

We just experienced this on the dnncommunity.org website. Basically, we installed under one URL, upgraded a couple of times, then added a new URL as primary and the original URL was still being used. From what I could tell, the first URL in the database was being used, despite a different domain name being specified as IsPrimary and Site Alias Mapping Mode being set to Redirect.

IMPORTANT: If this is indeed a bug, it could have massive impacts on the ecosystem. Websites may be incorrectly serving out the wrong domain names and the website owners may not have any clue that it's happening.

Steps to reproduce

List the steps to reproduce the behavior:

  1. Install DNN 9.1.1 and use a specific URL (e.g., domain1.org, and www.domain1.org)
  2. Upgrade to DNN 9.2.2
  3. Upgrade to DNN 9.3.2
  4. Add another domain, and set it to be the primary site alias now (e.g., domain2.org (primary), and www.domain2.org)
  5. View the website using the new URL/portal alias

Current result

Originally, it was redirecting to the correct primary URL, but a lot of time, it doesn't.

Expected result

The primary URL should be used when the setting exists and a HTTP 301 redirect should be performed is Redirect is the mapping mode.

Additional context

We managed to fix this by deleting the original primary alias (that was no longer primary) and adding it to the end.

Screenshots

image

Affected version

  • 9.3.2
  • 9.3.1
  • 9.2.2
  • 9.2.1
  • 9.2
  • 9.1.1
  • 9.1
  • 9.0

Affected browser

  • Chrome
  • Firefox
  • Safari
  • Internet Explorer
  • Edge
@mitchelsellers
Copy link
Contributor

Do you have a portalSetting value for DefaultPortalAlias

@WillStrohl
Copy link
Contributor Author

WillStrohl commented Jun 13, 2019

D'oh! That nasty little bugger. Yes, and now it's changed. Shouldn't that get updated if the default portal alias is updated?

@mitchelsellers
Copy link
Contributor

Yes it should, but was curious to see if that plays in. Honestly I think that setting can just go away

@WillStrohl
Copy link
Contributor Author

WillStrohl commented Jun 13, 2019

I'd agree with that. I don't recall why that separate setting was added to begin with... Isn't it legacy before the IsPrimary column was added to the PortalAlias table?

@mitchelsellers
Copy link
Contributor

Yup. It dates back to 3.x

@WillStrohl
Copy link
Contributor Author

Makes sense.... I vote to put it on "the chopping block" :D

@sleupold
Copy link
Contributor

AFAIK, PortalDefaultAliasis not used for UrlFormat = "Advanced"

@valadas
Copy link
Contributor

valadas commented Jul 29, 2019

So do we mark the property deprecated in 9.4.1 and remove this in 11 ?

@valadas valadas added this to the 9.4.1 milestone Jul 29, 2019
@sleupold
Copy link
Contributor

do we still support other UrlFormats?

@valadas
Copy link
Contributor

valadas commented Jul 30, 2019

I think it still works, but I would not see any reason to not use Advanced

@sleupold
Copy link
Contributor

sleupold commented Jul 30, 2019

@valadas,
In general, sites should use AdvancedURLs, but I'm having a big client with a large site, containing thousands of DNN pages with offers and they are using the tabid in the url to navigate the client on the phone and therefore using not even humanfriendly URLs.

@Mhtshum
Copy link
Contributor

Mhtshum commented Sep 19, 2019

@sleupold , @mitchelsellers , @daguiler , @valadas
Please help me to understand why portalalias is working well but when adding new language and enable content localization it starts redirecting to Primary alias whether mode is canonical or none

Is this not a bug or what am I missing here?
Or are there other settings need to be set when enabling content localization after adding a language?

@Mhtshum
Copy link
Contributor

Mhtshum commented Sep 23, 2019

Reported issue is #3017

@leedavi
Copy link
Contributor

leedavi commented Jan 29, 2020

image

@sleupold
Copy link
Contributor

@leedavi
the last one should be marked as primary as well. Login using the other alias and edit the French one to be primary.

@leedavi
Copy link
Contributor

leedavi commented Jan 29, 2020

Sorry,, I got disturbed and missed the description. The problem is I cannot change it. I had to do it form the DB.

I thought it might be related to this issue, but I see now this issue is closed.

@sleupold
Copy link
Contributor

@leedavi
you cannot edit the alias, you are currently using
you should be able to edit it while browsing using another alias (en-GB)

@leedavi
Copy link
Contributor

leedavi commented Jan 30, 2020

Ok thx Seb, you're right it could be linked to that. There was issues about missing portal alias, which caused this situation. Best we let this one rest until I re-create the issue with proof. The portal alias stuff is always a little odd in DNN9.

@Timo-Breumelhof
Copy link
Contributor

Timo-Breumelhof commented Mar 19, 2020

@hismightiness are you sure this was fixed? I have the same issue on an installation. I deleted the default alias in portalsettings (which was set to an old non existing alias) and the portal still serves both the www and non www alias, while being in redirect mode.

if (portalSettings.PortalAliasMappingMode == PortalSettings.PortalAliasMapping.Redirect

If I look at the code, I don't see how you could get a redirect if you delete the default alias from the PortalSettings table.

@WillStrohl
Copy link
Contributor Author

@Timo-Breumelhof Not that I'm aware of.

@valadas
Copy link
Contributor

valadas commented Mar 22, 2020

Many hosting control panels have a built-in feature to redirect www versions, could this be the case?

@leedavi
Copy link
Contributor

leedavi commented Mar 22, 2020

The PortalAlias functionality is very weak in DNN. It works, but is awkward to get your head around and often goes wrong. PortalAlias is the first thing to check when things do not point to the right place, And more often than not I fix it in the DB. It's difficult to pin down problems with the UI, but I certainly wouldn't be surprised if there is more than 1 bug, in certain situations when multiple langauges are used.

Is there any definitive documentation on how the portal alias should be setup for multiple languages and multiple urls?

@Timo-Breumelhof
Copy link
Contributor

Many hosting control panels have a built-in feature to redirect www versions, could this be the case?

No, this is on a pure windows server, no CP involved.
I "fixed" it by removing the portalalias and re-adding it

@Timo-Breumelhof
Copy link
Contributor

Ok, DNN seems to have lost the redirect again, I now resolved to adding a redirect in web.config, but there's definitely something wrong here.

@Timo-Breumelhof
Copy link
Contributor

FYI I also noticed this on the Evoq installation of a client

@Timo-Breumelhof
Copy link
Contributor

@skamphuis this one

@Timo-Breumelhof
Copy link
Contributor

@valadas we have been able to reproduce the issue on a local installation and we think we found a fix for it.

@skamphuis
Copy link
Contributor

Thanks. I'll be trying to do some more testing and submit a pull request this friday.

@valadas
Copy link
Contributor

valadas commented Jun 8, 2020

@Timo-Breumelhof @skamphuis when you say a fix, do you mean something environmental or something Dnn related, should we reopen this and expect a Dnn related PR to come in?

@Timo-Breumelhof
Copy link
Contributor

DNN related. I'll ping you when we have a PR.

@skamphuis
Copy link
Contributor

skamphuis commented Jun 9, 2020

@Timo-Breumelhof @skamphuis when you say a fix, do you mean something environmental or something Dnn related, should we reopen this and expect a Dnn related PR to come in?

I have the changes in my fork, here.
I didn't get to do much testing yet, which is why I didn't submit a PR yet.

@skamphuis
Copy link
Contributor

@valadas I have submitted PR #3832 . Please let me know if there's anything I need to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants