[Bug]: Configuring a User Profile Page Causes Invalid URL Paths to Return HTTP 200 Instead of Redirecting

Open
  • Is something wrong?
#7,599 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
backend

Research direction

Start in RewriteController.cs, in the RewriteParameters method, at the UserTabId condition that controls stripLoneParm, and reproduce with the Test URL Rewriting tool using a page URL with an extra trailing segment. Done means that ordinary pages with a User Profile Page configured drop or 404 unknown trailing segments, while profile and module URLs still resolve. The issue has no maintainer reply yet, so confirm the intended canonicalization policy before changing behavior.

Written by the indexing model from the issue text.

Description

Status: New
Is there an existing issue for this?
  • I have searched the existing issues
What happened?

I have identified an unexpected behavior in DNN's Advanced URL Rewriting mechanism that is directly related to the User Profile Page configuration.

When a User Profile Page is configured in the portal settings, DNN incorrectly accepts arbitrary trailing path segments on otherwise valid page URLs and returns HTTP 200 OK, displaying the original page content.

When the User Profile Page is not configured, DNN handles the same URLs differently, removing the invalid trailing segment and redirecting to the canonical page URL.

This behavior creates a potential SEO issue because an unlimited number of invalid URLs can return identical content with HTTP 200.

Steps to reproduce?
  1. Use a DNN installation with Advanced Friendly URLs enabled.
  2. Create a normal page named test, accessible at: https://www.example.com/test
  3. In the portal settings, configure a valid page as the User Profile Page.
  4. Navigate to an invalid URL such as: https://www.example.com/test/invalid-path-12345
  5. Observe that DNN displays the content of the test page and returns HTTP 200 OK, rather than rejecting or redirecting the invalid URL.
  6. Remove the User Profile Page configuration.
  7. Clear the DNN cache and repeat the same test.

Result: Without a configured User Profile Page, DNN removes the additional path segment and redirects to the canonical URL.

Current Behavior

With a User Profile Page configured (UserTabId = 22 in my test environment):

Requested URL:

https://www.example.com/test/fsdfds

Result from DNN's Test URL Rewriting tool:

Default.aspx?TabId=802&fsdfds&language=fa-IR

The invalid trailing segment fsdfds is preserved and appended as a query-string parameter without a value.

The page is rendered successfully with HTTP 200 OK.

Expected Behavior

Configuring a User Profile Page should not change how unrelated pages handle invalid trailing URL segments.

For example:

  • /test should return HTTP 200 OK.
  • /test/invalid-path-12345 should return HTTP 404 Not Found or redirect to /test according to DNN's URL canonicalization policy.
  • Valid dynamic URLs generated by modules or Extension URL Providers should continue to work normally.
  • The User Profile Page and its user-specific URL parameters should continue to function correctly.
Relevant log output
Anything else?
Technical Investigation

After comparing a fresh DNN installation with an installation upgraded from an older version, I found that the behavior was related to the UserTabId setting.

The following logic in RewriteController.cs, within the RewriteParameters method, appears to be relevant:

if (thisPortal.UserTabId == result.TabId || thisPortal.UserTabId == -1)

This condition enables the stripLoneParm behavior when the current page is the User Profile Page or when no User Profile Page is configured.

However, when a User Profile Page is configured, this condition is false for ordinary pages.

As a result, an arbitrary trailing URL segment may be retained as a standalone query-string parameter rather than being removed during URL rewriting.

This appears to explain why the behavior changes depending on whether UserTabId is configured.

Additional Findings

I verified the following:

The issue affects ordinary pages unrelated to the User Profile Page.

Completely nonexistent URLs correctly return HTTP 404.

The unexpected behavior occurs when an invalid segment is appended to an existing page URL.

DNN's Test URL Rewriting tool confirms that the additional segment is preserved when UserTabId is configured.

Removing the User Profile Page configuration changes the rewriting behavior.

The problem was initially observed in installations upgraded from older DNN versions, whereas a fresh installation without a configured User Profile Page did not exhibit the same behavior.

For comparison, the fresh installation generated the following rewriting result:

Default.aspx?TabId=169&language=fa-IR

It also returned HTTP 301, redirecting the invalid URL to the canonical /test URL.

The relationship with the User Profile Page configuration was subsequently confirmed through testing.

Suggested Fix

Please review the relationship between UserTabId, stripLoneParm, and URL parameter processing in RewriteController.RewriteParameters.

The handling of arbitrary trailing URL segments on ordinary pages should be independent of the User Profile Page configuration.

Any fix should preserve legitimate dynamic module URLs and user-profile routing while preventing unrelated pages from returning HTTP 200 for arbitrary invalid paths.

Impact

This issue can cause:

  • Duplicate content across an unlimited number of URLs.
  • Incorrect HTTP 200 responses for invalid URLs.
  • Search engine indexing and crawling problems.
  • Inconsistent URL rewriting behavior depending on portal configuration.

The User Profile Page is a legitimate and necessary feature. Disabling it should not be required to obtain consistent URL rewriting behavior.

Thank you for investigating this issue.

Affected Versions

10.4.1 (latest release)

What browsers are you seeing the problem on?

Chrome

Code of Conduct
  • I agree to follow this project's Code of Conduct
Dominant language
C#
Stars
1.1k
Forks
791
Avg merge
4d 5h
Merged PRs (30d)
27

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dnnsoftware/Dnn.Platform

All issues in dnnsoftware/Dnn.Platform

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.