This project is read-only.

Why did you bind the user to a specific blog?

Topics: Business Logic Layer
Jul 29, 2011 at 1:53 AM


I tried to realize SOS (Single Sign-On) with BE 2.5 and recognized, that this is not possible, because after signing in the user got a FormsAuthenticationTicket and a HttpCookie, which are bound to the specific blog. If I want to admin another blog, I have to login again with the same credentials and rights. That does not really make sense, or?

Is this a behavior for an upcomming feature or just a mistake?

I'am planning to offer BE to my customers and didn't want to start with customized binary code in order to be able to easily consume future updates...

Thanks in advance!

Jul 30, 2011 at 2:10 AM
Edited Oct 24, 2011 at 8:27 PM

You just change the provider for the security in the web.config file:


<add name="MSSQLMembershipProvider"   
         type="System.Web.Security.SqlMembershipProvider"   <------------ Security database
         applicationName="BlogEngine.NET" />

Its possible for BE to use the same login site wide.

Exactly how to do it not sure but the above link and code should get you started :)

Also do a search for "Using BlogEngine.Net with single login" and similar quriers you will find your answer :)

If you need more help and no one else had reply yet then let me know

I will do my best to help you out :)

Hope this helps you out,

Brian Davis

Java Blog

Jul 30, 2011 at 11:31 AM

No, I did all, what normally would be necessary.

The problem ist, that you get a separate custom FormsAuthenticationTicket and HttpCookie for every login in a blog. Please take a look in BlogEngine.Core.Security : IHttpModule. I marked the important parts red:

public static string FormsAuthCookieName




return FormsAuthentication.FormsCookieName + "-" + Blog.CurrentInstance.Id.ToString();




public static bool AuthenticateUser(string username, string password, bool rememberMe)


FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(











       HttpCookie cookie = new HttpCookie(FormsAuthCookieName, encryptedTicket);




I hink, you see it now, too: SSO is not possible without modification of the source code.


Jul 30, 2011 at 4:41 PM

Looks like they changed it for BE 2.5  I know versions lower than BE 2.5 all what was needed was a change in the security provider.


So I think they need to take this out of the core and have in place options to select like the options to select which database provider to use (xml or database) to use.


This should not be baked into BE core through.


In the


Page there should be a drop down menu


Security Provider:    [BE , Database, {Single Sign on Services} like "Facebook,Twitter,Yahoo" and etc listed]


This way there is no manual changes or "Baked" in code its abstract for the user to pick what they want to use.



HeikoHinz:  Well sorry about not able to help much farther, but if you are in a hurry to get this done and no one else had

reply to this post on how to do a custom fix for this then send me an email and I will try to figure out

how to solve this for you if you are unable to do so.


Have a good Day,


Brian Davis




This in theory would be a nice feature for a future release.   :)



Development team is this possible to do?  If so how hard would it be to do?



Jul 30, 2011 at 6:24 PM

Thank you very much for the informations :-)

I think, I will change the code and recompile it.


Jul 30, 2011 at 8:03 PM

Could you share the code when you are done?


I would like to see if you don't mind :)


Have a Great Day!


Brian Davis

Jul 31, 2011 at 1:22 AM

That's all what you have to change in BlogEngine.Core.Security (/Security/Security.cs):

private static void ContextAuthenticateRequest(object sender, EventArgs e)

        if (authTicket != null) // && !string.IsNullOrWhiteSpace(authTicket.UserData) && authTicket.UserData.Equals(Blog.CurrentInstance.Id.ToString(), StringComparison.OrdinalIgnoreCase))


public static string FormsAuthCookieName
       return FormsAuthentication.FormsCookieName;// +"-" + Blog.CurrentInstance.Id.ToString();


Jul 31, 2011 at 1:37 AM

So with only the above changes it works?


Thats amazing thanks for sharing :)

Jul 31, 2011 at 3:21 AM

Yes, but of course the settings for the machineKey and authentication including providers in each web.config file should match

Jul 31, 2011 at 1:28 PM

This change is definitely intentional.  It was made for multiple blog scenarios.  Each blog should be considered a separate blog, and each blog has its own set of users, etc.  Without this code, a person logged into one child blog would have access to the other blogs ... which for most people is not how they would like it to work.

The code change you posted where you commented out the check for authTicket.UserData is the correct change for what you're looking to do.  We won't make this change to BE for the reason described above.  You do want to make sure though that you have the same set of users in both blog instances.  Meaning, if you log into Blog A under "john" and then go to Blog B where "john" is not a user there, that could cause problems.

Jul 31, 2011 at 2:51 PM

That's seems to be right, but when I use the SqlMembershipProvider, I will have the same users with identical rights in every blog and then it makes not really sense, or?

I think, what you (we) need is a adminstration for assigning the users to the different blogs. It's a little bit more work, but then it would be clean... ;-)