npeeters wrote:

Browser issue could have something to do with Cookie handling. That could explain 'invalid password' working, since that is a simple postback. Any patch applied? Installed some pop-up blocker, anti-phishing, personal firewall or other kind of stuff?

I've turned off all non-essential software and have tried 3 different browsers ( one newly installed after this problem appeared).

I've stepped through the code and I'm definately being logged in.  Does anyone know where the determination is made about showing controls in edit mode along with the cotrol panel - I could put a breakpoint on it?

I had a similar problem with my DNN installation the other day. I was unable to login in as Host or Admin with any of my passwords that I could think of. I may have just forgotten what I had entered don't know. I needed to reset my Host and Admin passwords to something that I know now. Here is how I reset my password.

1. Registered a new account on my DNN with dummy username such as Test with the password that I wanted for Host.
2. You do not have to approve this user.
3. Look in SQL server at the aspnet_Membership table. Find the record for this new Test user.
4. Copy the Test user's hashed Password and PasswordSalt into the Host Account's Password and PasswordSalt field.
5. You should now be able to login to your Host account with the new password.
6. Delete the Test account from your system.
7. Change password of Admin through Host account or repeat steps for the Admin account.

I am not sure if these steps will help in your exact situation, but they helped me reset my Host account password.

portvista wrote:

Solution: delete all your cookies in IE. Worked for me, but of course now I lost all my cookies. Not sure why this happens?

I tried that along with using 2 other browsers.  Deleted cookies, files, etc. This didn't fix the problem.

J7Mitch wrote:

Can you try from another machine?  If it's on the internet I could try. If you can register a new user, you can go directly into the db and copy the encrypted password from that user to the user you are trying to login with (make sure you copy the password salt also).

Tried logging in from another machine and have the exact same problem.  Could this be a problem in IIS?

I was just going to ask what your indication was that you were not logged in. Are you sure it's not just that you are in "Preview Mode"?  Do you see a "logout" link where the "login" link usually is?  Do you have a link with the Users name to update the profile or does it say "Register"?

In Skin.vb there is a check for the Preview Mode cookie. 

J7Mitch wrote:

I was just going to ask what your indication was that you were not logged in. Are you sure it's not just that you are in "Preview Mode"?  Do you see a "logout" link where the "login" link usually is?  Do you have a link with the Users name to update the profile or does it say "Register"? In Skin.vb there is a check for the Preview Mode cookie.

It acts exactly like I'm not logged in.  There is no preview mode, control panel, and the main page continues to say "Register  Login" and I'm returned to whatever page I was on before I clicked "Login".  I did just test on another machine and get the same results.  Here's where this is at by my logic:

Not the database (restored backup and still has problem)
Not the browser (tried 3 different and a remote machine)
Not the code files (re-installed DNN from scratch, also my DNN2.0 site doesn't work either)

What's left? - IIS?  I'm going to try and re-install.

Well no luck there either.  This is really shaking my confidence in DNN.  Before I go ahead an Nuke my machine does anyone have any other suggestions to try?

Wow, that is freaky.  You know, if you can get on the server that IIS is running on and try logging in from there it might work.  It sounds like maybe something between you and the server is keeping you from getting the Auth cookie.  This can happen with some firewalls or proxies.

You can also look in your cookies folder locally and see if the one for that domain is getting updated at all.

J7Mitch wrote:

Wow, that is freaky.  You know, if you can get on the server that IIS is running on and try logging in from there it might work.  It sounds like maybe something between you and the server is keeping you from getting the Auth cookie.  This can happen with some firewalls or proxies. You can also look in your cookies folder locally and see if the one for that domain is getting updated at all.

I'm running locally.

In the code I see when the Authentication Cookie is being set (in PortalSecurity.vb) during login:
                    FormsAuthentication.SetAuthCookie(Username, CreatePersistentCookie)

However, when in default.aspx after postback, in the InitializePage, the following is FALSE:
            If Request.IsAuthenticated = True Then
Shouldn't it be true?

Also, there are 2 cookies set:
? request.Cookies(0)
{System.Web.HttpCookie}
    Domain: ""
    Expires: #12:00:00 AM#
    HasKeys: False
    Item: <cannot view indexed property>
    Name: ".ASPXANONYMOUS"
    Path: "/"
    Secure: False
    Value: "AcWZKD-qGoJmNTZkMTRlZi0zNGYwLTQ4NmUtYTVmOC1hZjI4NzY2YjBmNTQ1"
    Values: {System.Web.HttpValueCollection}
? request.Cookies(1)
{System.Web.HttpCookie}
    Domain: Nothing
    Expires: #12:00:00 AM#
    HasKeys: False
    Item: <cannot view indexed property>
    Name: ".DOTNETNUKE"
    Path: "/"
    Secure: False
    Value: "10B94E7259DF065ED7C6488098B8F9E826F3FEE2B851EC65A5B3DB8E5C50A7BE61FACC3F0B2DBA6A8021C12628B33C41FC2D416BC0FB116952DB800F77E3C9FA"
    Values: {System.Web.HttpValueCollection}

It has to be cookies, because that's how Forms Authentication works. These are the EXACT symptoms of improper handling of .NET authentication via save cookie method. When you allow a user to login via cookie, you still must actually log the user in and assign the user id with the correct permissions for that session. If you don't, this is exactly what happens! I don't know how eactly DNN is screwing this up, but I have to clear my cookies occassionally -- I just hope it doesn't do that for all users. Check that there are no cookies in your cookie IE folder, empty cache, delete files.

portvista wrote:

It has to be cookies, because that's how Forms Authentication works. These are the EXACT symptoms of improper handling of .NET authentication via save cookie method. When you allow a user to login via cookie, you still must actually log the user in and assign the user id with the correct permissions for that session. If you don't, this is exactly what happens! I don't know how eactly DNN is screwing this up, but I have to clear my cookies occassionally -- I just hope it doesn't do that for all users. Check that there are no cookies in your cookie IE folder, empty cache, delete files.

I agree.  The problem is I've done all the cookie and cache clearing I can with no luck.  Also, after I had this problem I installed Opera and it had the same problem.  I assume Opera uses its own location for persisting data...Also, I tried logging on from another machine and it too had this problem.

Yes, Request.IsAuthenticated should be true after the Auth Cookie is set.

One of the things you might run into when running on localhost is that your cookie has to be shared by all the apps that are running under the one IIS site in their own virtual directories. 
This will sometimes get overlapping information in it and is the reason you sometimes have to delete it.  You don't have to clear all your cookies though, just delete the localhost cookie(s).

Cookies are identified by domain which is localhost in this situation

Another time you can run into a problem like this is when you have child portals, but not parent portals because the parent portals have thier own domain or subdomain names.

So deleteing the cookie may be the answer and would explain why you can't login to the DNN2 portal any more also.
That doesn't explain why you get the same symptoms on another machine and on other browsers though.

Hey.  I had the same problem temporarily.  I went to Admin->Settings...Advanced, and set my login page to my home page.  Hey, what do I know, right? Well, that was the kiss of death.  If you have access to query analyzer, open that, open a query window, and do the following:

use (whatever database you named)
select * from Portals

see if the column for 'LoginTabID' is <NULL>

if it's not, then perform the following in query analyzer...

use (seeabove)
update Portals
set LoginTabID = NULL

select * from Portals

It sounds to me like it's *possible* you changed the default page for the login.  For the life of me, I don't unnerstand why in *practice* this option is there.  In *theory* it makes sense, but since there's zero documentation for it, well...I'll leave it at that.  Please let me know what it says in either case for that column in the Portals table....perhaps we can go from there...It needs to be NULL so the code can go to the normal login page.

And whoever has the documentation for ALL the database concepts and changes...why are you not making this available to us?  It's like a black box right now (which by the way is actually an orange box, as I've learned...but that's another story..;-)).  Seriously though, the docs for the DNN database are non-existent.  And as the engine for the product, it's mind-boggling that ALL database issues get ignored by members of the core team responsible for it here.  I've posted at least a half dozen questions about the DB changes for 3.x.  Never, ever rec'd a reply from a core team member.

So that's my rant.  It's not like you folks are being paid or anything and I realize this.  So let me know if this helps, k?

Resolved!

Here's what I did.  Removed .Net Framework, Removed IIS, Reinstalled IIS ReInstalled .Net Framework.  Curious how setting the skins could cause this type of catastrophic problem.  Very strage behavior indeed.

Cheer and thank you all for your support!

If there are any bugs in DNN, the skinnning system are where they are at. It's the most complicated and hacked up "template" system I've ever seen.