This project is read-only.

Authorization issue - can't administer site

Jul 11, 2008 at 6:05 PM
Edited Jul 11, 2008 at 6:06 PM
I'm running into an interesting issue where I seem to be able to log in successfully (at least it says, "logged in as admin"), however when I attempt to access a protected page (e.g. EditConfig.aspx), it says I do not have access.  I also do not ever see the administration navigation bar.

This is what happens in my hosted environment (GoDaddy, IIS7, integrated mode).  I am able to get access to the administration functions on my local machine (Vista, IIS7, integrated), however only when the user name is 'admin' - if I add a new user with another name, I can log in successfully, but never see the admin navigation bar even if I give add this new user to the admin role.  This may or may not be a seperate issue, but it seemed related.

This is a new installation using the bin distribution of the latest release (2.1.8102.813).  This is my first install, so it may just be a simple case of RTFM, but I read as much as I could find on it.

This may or may not be related to the issue over here:  I am not running off a virtual directory, so I don't think the cookie path issue applies to me.
Jul 12, 2008 at 1:30 AM
This is usually a bad edit of the "siteSecurity.config" file.

If you have edited the security file check your xml format! If that appears ok then try this.

See if you can login successfully using the default "siteSecurity.config" file?

If that works, then go into SiteSecurity.config and set a text password.

Then, in site.config, set <EncryptLoginPassword>false</EncryptLoginPassword>.

If you can login from there, set it all back the way you want it.


Jul 14, 2008 at 3:34 PM
Edited Jul 14, 2008 at 3:49 PM
Yeah, I actually tried all that and none of it seems to affect anything.  I have done some more debugging and come up with some interesting results:

As I said, this all works on my local machine (from which I am doing a straight copy to my host's FTP server) so debugging on my local machine is useless, since there's nothing to debug.  That being said, I created a little diagnostics page outputting the values of HttpContext.Current.User and Thread.CurrentPrincipal to compare the values between my local machine and production, and they are different, even with the same code & siteSecurity.config.

After successfully logging in on my local machine, the values are:
  • HttpContext.Current.User:  admin
  • HttpContext.Current.User.IsInRole("admin"): true
  • HttpContext.Current.User.IsInRole("contributor"): false (expected) 

    After "successfully" logging in to the hosted instance (again, using the same siteSecurity.config), the values are different:

  • HttpContext.Current.User:  admin  <-- This is the same.  I am logged in just fine.
  • HttpContext.Current.User.IsInRole("admin"): false
  • HttpContext.Current.User.IsInRole("contributor"): false (expected) 

    Looks like setting the roles on the new Prinicpal is failing on my hosted instance - the new principal is created just fine, yet none of the roles have been applied.  Are there any settings on my host or web.config that could affect this?

  • Nov 30, 2009 at 8:52 PM

    This link explains how to fix this issue:

    Basically if you have a MembershipProvider defined in the web.config file of your main web site (not DasBlog) then you need to do the following:

    add the following to the web.config for dasBlog

    <membership defaultProvider="none">
       <clear />
    </membership > 

    <roleManager enabled="false" />