This project is read-only.

Installation of 1.4.5 but can not admin login

Jan 30, 2009 at 2:46 PM
I have installed the app, all went well, but when I try to admin login the same page login.aspx is simply refreshed, I have no idea where to start

Jan 30, 2009 at 10:53 PM
You're using admin for the username and admin for the password?  Just checking.

It sounds like the authentication cookie isn't sticking.  If you're trying to log in using IE on localhost, IE will often treat that as a restricted zone or local intranet zone where settings are tight.  If this is the case, you can try putting localhost in the Trusted Sites zone.  When you're on the login page, in IE's status bar, bottom right, it'll say 'Internet' or 'Restricted' or 'Local intranet' or 'Restricted'.  Double click on that to bring up the internet security properties.  Highlight 'Trusted Sites', click the 'Sites' button, and add http://localhost as a site in the Trusted Sites zone.  You may need to uncheck the 'Require server verification (https:) for all sites in this zone' checkbox at the bottom.
Jan 31, 2009 at 4:21 AM
Edited Jan 31, 2009 at 4:21 AM
I too am having a bit of trouble logging in as well.
I have logged in per the http://localhost as described in the instructions using - admin / admin and have added two more user accounts login names and passwords. I then changed the user account admin password to a new password.
I can consistently login as long as I am viewing the site view http://localhost/BlogEngineWeb/ but when I go out to the internet and try to login at i get a refresh asking to login per the names or the admin account.

I am stumpt...
Jan 31, 2009 at 7:20 AM
So, you don't get a message saying "login attempt was unsuccessful" ?  You just get redirected back to the login page and you're not logged in?

Could be the same issue where cookies aren't sticking.  If you're using IE, you could try adding to the trusted sites list.  If that doesn't work, I'd suggest trying a different browser to see if it makes any difference.
Jan 31, 2009 at 7:59 AM
I have the similar problem hosting on Windows 2008. Attempting to log in with admin returns to the Welcome page. Cookies are enabled and IE set to Trusted sites (also tried local intranet). IIS log shows a 302 error for POST /login.aspx. Network Service has full control over all folders. Any other suggestions will be appreciated.
Jan 31, 2009 at 9:24 AM
Edited Jan 31, 2009 at 9:27 AM
Ben, thanks for trying to help... we certainly appreciate it.

As per the message "login attempt was unsuccessful", i do get this message on two of the accounts on the World Wide Web... as stated earlier, i created two accounts beside the existing admin account. I gave one account, Editor rights and the other Admin rights.
The two administrator accounts, I do get the message "Your login attempt was not successful. Please try again." but on the Editor account, all it does is an auto-refresh without any message.
As for logging on to my application via http://localhost, I can use all three accounts and login to the web application and do modifications...
Seeing this is done on my own 2008 server in my home, I have full control... My entire II7 Site, Default Web Site has Network Services with full control extending downward to all subfolders inheriting the permission attribute. But as a precaution, I have checked the App_Data folder to make sure it inhereithed these rights. So far so good... I also made sure the all folders in the directory are Not set to read only.
On Install, I created a BlogEngine MSSQL 2008 database... ran the setup script, created a login user name and password, set permissions for the database login user name granting dBRead and dBWrite for the database, then plugged in the connection string in the web.config file. All seemed to work fine... I am going to assume this because I can login to the blog application via localhost and add comments, upload pictures and/or do anything just as if i were doing this on the world wide web...
LOL, i am so confused...
I am not giving up, there has to be a setting I am missing, or something in the application somewhere that is under conflict. either way, if I do resolve this, i will make sure to post back to you guys... In the meantime, please let me know if you have any suggestions, or if you want me to check or try something on my server for you that may resolve the issue so you can pass the info onto those guys at GoDaddy or your hosting provider. 

thanks again Ben...
Jan 31, 2009 at 6:30 PM
On Windows 2008, I wasn't able to remove the read-only attribute from the folders although removing them from files was possible using  cmd:

attrib -r +s drive:\<path>\<foldername>

This change did not resolve the log in issue because the read-only attribute was not removed from the folder itself.

If you would like to review the Microsoft KB article, it is 
Jan 31, 2009 at 7:22 PM
@dslaby: I could be wrong, but you should probably be okay if the read-only attribute isn't going away for some of the folders.  On some test BE setups I have, I too can't completely remove the read-only attribute, but I can still log into BE, create posts, etc.

Have you tried logging in with a different browser?  Firefox is free.  A couple of weeks ago, someone else was having login troubles similar to you and flashriver.  Here's the thread.  If you try logging in with Firefox, and it doesn't work like it isn't working in IE, try checking your cookies in Firefox after attempting to log in ... I described this in that other thread.  Upon a successful login, there should be 2 cookies -- .BLOGENGINEROLES and .AUXBLOGENGINE.  What cookies do you see in Firefox after trying to log in?
Jan 31, 2009 at 7:33 PM
@flashriver: So you have one BE installation, and when you try to login to that single BE installation via localhost, you are successful with all 3 accounts ... but when trying to log into the same BE installation via the WWW address, you get the login attempt was unsuccessful message for both admin accounts and just a page refresh for the editor account.  Is that right?  You don't have it setup as two different sites within IIS pointing to the same physical location, right?  One BE installation, one website in IIS and one app pool in IIS, right?

For the editor account where you're just getting a page refresh, like I suggested to dslaby, I'd try logging in with Firefox to see if that makes a difference.  If it still doesn't work, I'd suggest trying to check your cookies in Firefox as I describe in this other thread.  If the login is successful, there should be both .BLOGENGINEROLES and .AUXBLOGENGINE cookies.  These are session cookies which aren't easy to check for in IE ... which is why I suggest trying Firefox since you can pretty easily view all cookies in Firefox.
Feb 1, 2009 at 12:40 AM
In my case, I do get the msg saying Your login was unsuccessful, try again

I added the site to the trusted, no chg

great software when u can;'t login to it.

Note: I have this loaded to a real site, not on a laptop localhost environment.

Feb 1, 2009 at 12:47 AM
Adding your site to the Trusted Sites list was a recommendation if you weren't getting a "login unsuccessful" message back, and the page was just refreshing.  But since you are getting a "login successful" message, yes, Trusted Sites isn't relevant.

If you're using the default XML provider, you'll find a users.xml file in the App_Data folder.  Open that up, and you should see something like:

    <LastLoginTime>2007-12-05 20:46:40</LastLoginTime>

The password is hashed.  If you clear out the password contents, then you should be able to log in using the value in the <UserName> node and the default password of "admin" ... IOW, the username will be "admin" and the password will be "admin" once you clear out the password contents.  You'll want the users.xml file to look like:

    <LastLoginTime>2007-12-05 20:46:40</LastLoginTime>

Actually, BlogEngine is pretty good software.  If you browse through the Discussions here, you'll find hardly anyone with this problem.
Feb 1, 2009 at 1:01 AM
Also, if you modify the users.xml file, BE might have the old users data cached and not detect the change in the file.  Overwriting your web.config file with itself (i.e. re-uploading it to your site) should clear the cached data so the users.xml file is re-read.
Feb 1, 2009 at 1:19 AM
Well - there is no users.xml file as you mentioned?

So, I created one using what you provided, no chg, same result?

Feb 1, 2009 at 1:28 AM
Are you storing any data in a SQL database?  If so, then the users might be stored in the be_Users database table (rather than the users.xml file).

Do you have any files in your App_Data folder, by the way?  You should have blogroll.xml, categories.xml, newsletter.xml, pingservices.xml, roles.xml, settings.xml, stopwords.xml and users.xml.  Then there's folders that should be there too.  If you're using a database, some of these files may not be there.

Also, were you ever able to log into BE?  Or is this a new installation?  Who installed it?
Feb 1, 2009 at 1:40 AM
FYi - I was concerned by the lack of what should be an obvious file, so I reinstalled, and fancy the fact now I can login, so I appreciate the help, now to see if I cna make all the harder stuff work
Thanks for the help., must have been a fault install to start off
Feb 1, 2009 at 7:10 PM
FYi - Isn't it funny how life has many side tracks just waiting up the way just for you...  I wish I could say that the problem is fixed... Unfortunately, the BlogEngine is working by design which in itself is the problem the way that I was forwarding from my Domain name to my IP address on my server.  Here is the fault... I am forwarding the domain name, to my server ip address / website... hence... the redirect service does what it is suppose to do. Now this said, I also had the redirect forwarding Masked so that the Okie-Chopper would show up instead of the IP address.
What does this do? Well it's all in the way that masking works which throws the login process in the application for a, I'm sorry, I can not find the code to execute the login, so I am going to redirect you to try again.
In case of a URL Masking, the Domain Forwarding servre sends the client a Frames page where the Frame Source contains the destination URL that is specified. This ensures that the URL in the address bar of the browser does not change though the client sees the destination page. 
Older browsers cannot resolve a Frames based page, moreover, search engines have problems trying to spider a Frames based website. With this said, the code to execute the logon to the BlogEngine has problems with a Frames page as well. It can not find the trigger on the Frames page which encapsulated the website because it has none. lol - Oh Well, Smell... back to the drawing board to figure out how to get a work around for this... at least, I can turn off Masking and logon now when I go to
I know I was not much help for you guys who are having problems with the logon via your host provider, but you can commit my problem in your high memory for use at a later date perhaps or related matter about Frames pages...
Thanks everyone for posting all the messages, I appreciate you guys... may all your blogs be blognanomous...

- Flash