This project is read-only.

Create page in control panel that requires login

Dec 6, 2010 at 5:54 PM
Edited Dec 6, 2010 at 6:01 PM

I have a folder called members in my website with a web config that requires a login for any files in the folder.  Is it possible to create a new page in the control panel and make it require a login or be able to put it in my members folder.  I would like the page to have the capability of being edited easily as these pages have BE 2.0 RC? Thank you.

Dec 6, 2010 at 6:22 PM

In BE 2.0, based on a person's role, it can be setup to allow a person to create new pages.  For editing an existing page, it can be setup to allow a person to edit pages.  But they would be allowed to edit all pages, not just a specific page.  Meaning the permissions aren't done at the specific page level.

Customizations could be made to your specific blog, which might be the only way to allow a certain role (or people in that role) to be able to edit just a single page, while not allowing them to edit any other pages.

Dec 6, 2010 at 6:26 PM

Actually I think I need to make what I desire clearer Ben, I want to create a page as admin and make the page require a login for users to read it, I am wondering if I can do something like this with a BE page or do I have to do it like my other stand alone pages in my members folder?

Dec 7, 2010 at 2:51 AM

I think I understand.  You could create a standalone .ASPX page in the members folder, as you've been doing.

Another option is to modify page.aspx.cs (in the root folder), and add a check there.  In there where ServePage() is, there is this existing code:

if (pg == null || (!pg.IsVisible))
	this.Response.Redirect(string.Format("{0}error404.aspx", Utils.RelativeWebRoot), true);
... after that above existing code, you could add either (A) ...

if (pg.Title.Equals("my front page", StringComparison.OrdinalIgnoreCase) &&

.... or add (B) ...

if (pg.Id == new Guid("0b17582f-1154-4c8b-8895-2b00ecc89187") &&
The first one (A) checks for the Page by title.  The second one (B) checks for the Page by GUID.  If the page title won't change, you could go with (A).  But if the page title might change, then (B) might be better since the ID will always stay the same for a particular page.  You can get the Page ID in the DB, or by looking at the "id" in the URL (address bar) when you edit the page in the control panel.

Dec 7, 2010 at 2:55 AM

A 3rd possibility is to create an Extension that does this check.  The advantage of the extension is that it would be your own extension that is separate code from the BE code (page.aspx.cs).  If you modify page.aspx.cs (as I did above), then when you upgrade BE in the future, you need to remember to put this code back in.

With an extension, it would be a new extension that isn't part of the BE code, so wouldn't be something you need to add back in after a future BE update.  Technically you need to make sure the extension (.CS file) is there, but not something that will be overwritten by a future BE update or where you need to open up the file and edit it like you would have to with page.aspx.cs.

The standalone page in the Members folder also has this advantage of not needing to add something back in after a future BE update.

Dec 7, 2010 at 3:56 AM

Wow a lot to digest, thanks Ben. I think I should investigate on how difficult it would be to create an extension first, if it is beyond me I like option B.  The standalone page in the Members folder works great but to add something I  need to edit with VWD and upload, I like editing on the server.

Dec 7, 2010 at 3:07 PM


Option B is working nice, can I setup several pages this way, or am I limited to 1?  Thanks

Dec 7, 2010 at 6:36 PM
Edited Dec 7, 2010 at 6:37 PM

Here's an extension I just created that does the same thing as Option B, but the code is in this separate extension ... so you don't need to modify page.aspx.cs (you can restore it to what it was before).  You can easily add more page IDs to this by adding more lines (_restrictedPages.Add(.....)) and put the other page GUIDs in there.

EDIT:  Put this into a new file in the App_Code\Extensions folder.  You can call it PageAccess.cs, or another name if you'd like (ending with .CS).

namespace App_Code.Extensions
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Web;
    using BlogEngine.Core;
    using BlogEngine.Core.Web.Controls;

    [Extension("Restricts page access to authorized users", "1.0", "BlogEngine.NET")]
    public class PageAccess
        static PageAccess()
            _restrictedPages.Add(new Guid("0b17582f-1154-4c8b-8895-2b00ecc89187"));

            Page.Serving += new EventHandler<ServingEventArgs>(Page_Serving);

        private static List<Guid> _restrictedPages = new List<Guid>();

        private static void Page_Serving(object sender, ServingEventArgs e)
            if (e.Location != ServingLocation.SinglePage)

            if (Security.IsAuthenticated) { return; }

            Page page = sender as Page;
            if (page == null) { return; }

            if (!_restrictedPages.Contains(page.Id)) { return; }

            HttpContext context = HttpContext.Current;



Dec 7, 2010 at 7:44 PM
Edited Dec 8, 2010 at 2:30 AM

Wow! This is just too cool Ben, it seems I am always thanking you for something but this is absolutely the greatest thing since cold beer and fish tacos.

I hope you make it available for other BE users to enjoy.

 I am getting ready to test BE 2.0 RC live today, I actually entered several hundred users in SQE_CE by cutting and pasting, I will be losing all my blog entries but am starting with way fewer categories, the blog entries are mostly outdated anyway.

 I love most everything about 2.0 with only one very small exception, it is more clicks to enter posts but the new interface is great.

Thank you for all your generous time and expertise you have given me since I have been using BE.


Testing BE 2.0 RC and SQL_CE at to see what breaks.