DNN Redirects to Login

Question

I'm upgrading my DNN application from 07.00.02 to 07.03.04 and post installation all my portal redirect to the login page. All portals are configured with a landing page configured to allow the 'All Users' role View access. Has anyone else encountered this issue after upgrading?

I have made numerous changes to the web.config, including setting the authentication mode to none and sadly the issue remains.

The IIS log shows there's two GET attempts to hit the root of the site resulting in 302 , then a GET request for the login tab with a 200 response, please see below:

2015-02-05 05:45:01 127.0.0.1 GET / - 80 - 127.0.0.1 Mozilla/5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/40.0.2214.94+Safari/537.36 - 302 0 0 4203

2015-02-05 05:45:01 127.0.0.1 GET / - 80 - 127.0.0.1 Mozilla/5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/40.0.2214.94+Safari/537.36 - 302 0 0 3

2015-02-05 05:45:01 127.0.0.1 GET /Default.aspx TabId=4330&ctl=Login&returnurl=%2f 80 - 127.0.0.1 Mozilla/5.0+(Windows+NT+6.3;+WOW64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/40.0.2214.94+Safari/537.36 - 200 0 0 354

Answer 1

Can you get logged in yourself? I would start by checking the page permissions, perhaps permissions got overwritten on upgrade (never seen that myself).

You might also check if the landing page is still configured?

Answer 2

Here's the solution and an explanation of the root cause of the issue.

There appears to be a change in the DNN framework between versions 07.00.02 and 07.04.00 where the RoleName from dbo.vw_TabPermissions is being used instead of the RoleId in the same view. This is being returned by the dbo.GetTabPermissionsByPortal stored procedure. In 07.00.02 I've not had any issues but after the upgrade given there's some legacy data in the dbo.Roles table for RoleId -1 that was created at a time when the -1, -2 and -3 system roles did no appear to exist. In my system a non-system role was created for custom functionality hence the RoleName was not 'All Users'.

Updating the RoleName field to 'All Users' corrects the issue and looking at old backups when the system was at version 05.06.03 there were no records in my database for RoleIds -1, -2 and -3. Historically the Roles appear to have been hard-coded in most places like they still are now in dbo.vw_TabPermissions at version 07.04.00.

So, the root cause was bad data identified with the SQL Profiler after a lot of debugging .Net code where the problem didn't exist.