I am using a third party login module and have a custom login page.  Everything was working fine until I decided to take a shortcut reassigning page permissions.  The custom login page is subordinate to the Home page and both were visible to 'Unauthenticated' users and everything worked fine until I changed permissions on the home page to a  'User' and then propogated that setting to subordinate pages.  Consequently, when I go to 'Login' because only that 'User' can see the login page I get a 'Cannot display the webpage error'; something of a Catch 22 situation.

I have gone into the database and identified the TabID of the 'Login' page in the 'Tabs' table and have then gone to the 'TabPermission' page and for that TabID I have tried both settings shown below attempting to gain access to the Login' one again; neither works.  The 'Home' page displays irrespective of how the 'View' permission is set.

Can anyone tell me how I might get the 'Login' page to display for Unauthenticated users again, I at a total loss?

Regards
Taz

Thanks Antony but the issue is that I cannot open the Login page because I must first be logged in; that's what I meant by a Catch 22 situation (perhaps my age is showing and you haven't seen Catch 22 the movie). 

Any recovery must be done from the database. 

I have set up two local DNN instances and synchronised them so that they are identical including a custom Login page using Redgate Data Compare.  I then reproduced what I did on my live site in one of those instances and recompared the databases.  The only changes Data Compare identified occurred in the TabPermission table so I manually reversed those changes except for the record number which I couldn't change; it still didn't work.  I then resynchronised the second instance of DNN so that record IDs were reset to original as well and then for some reason that I haven't fathomed yet both DNN instances refused to work; at this stage I am suspecting finger trouble so I am still researching.

The interesting thing that I can't fathom at this stage is why when I reset the data to the original configuration it still didn't work; the Record IDs shouldn't make a difference unless there is some relationship which ties them to another table.  However, the Redgate software didn't identify that relationship.  I'll run the Redgate Dependency Tracker over the database and see what it shows in the way of relationships, perhaps that will give me some hints.

Anyone with other ideas please feel free to jump in with suggestions.

Regards
Taz