U4-6342 - UmbracoEnsuredPage doesn't work in 7.2.2

Created by Anders Bjerner 01 Mar 2015, 23:03:15 Updated by Sentient 30 Sep 2015, 03:20:46

Is duplicated by: U4-6332

Is duplicated by: U4-6335

Relates to: U4-6352

Relates to: U4-6335

Steps to reproduce:

  • Install new Umbraco 7.2.2 (or update from earlier version)
  • Create new .aspx file and inherit from UmbracoEnsuredPage (the one in Umbraco.Web.UI.Pages)
  • Login to Umbraco
  • View .aspx file in browser => User is redirected to /umbraco/#/login/, then to /umbraco/#/ since the user is already logged in

Doing the same works fine in 7.2.1.

This may be the same as reported in http://issues.umbraco.org/issue/U4-6335 but since I'm not sure, I'm creating this as a new issue.

1 Attachments


Sebastiaan Janssen 02 Mar 2015, 09:30:47

I've tried this with the built-in umbraco/dialogs/assignDomain2.aspx page (which uses Umbraco.Web.UI.Pages.UmbracoEnsuredPage) and as far as I can tell it's doing nothing different from 7.2.1? So when you say "Doing the same works fine in 7.2.1." what do you mean? Is the behavior different and if so, how please?

Anders Bjerner 02 Mar 2015, 09:54:34

The problem is that the user seems to be redirected even if he is logged in. The normal behavior would be to see the content of the page rather than being redirected. This worked fine in 7.2.1 and earlier versions, but not 7.2.2.

For instance in Warren's Analytics package, we open a popup with an .aspx page to handle the authentication. In 7.2.2 this page will simply redirect back to the login page even though the user is logged in.

Ali Sheikh Taheri 02 Mar 2015, 13:52:19

I am getting similar issue on v7.2.2 for a custom section on my package (Conveyor). https://our.umbraco.org/projects/backoffice-extensions/conveyor/conveyor/61813-4010-Error

I don't get this error on v7.2.0

here is screenshot:

Ali Sheikh Taheri 02 Mar 2015, 13:59:10

I just looked at the source code and I am using UmbracoAuthorizedController and that returns the above screenshot. It might be the same issue if not please let me know to create a new issue for it.

Tim Geyssens 02 Mar 2015, 17:38:56

Got the same in Optimus since 7.2.2 with custom backoffice pages, according to Shannon your custom route needs to live in /umbraco/backoffice for it to be recognised as a back office controller (in addition to inheriting from UmbracoAuthorizedController)

Anders Bjerner 02 Mar 2015, 18:10:54

I don't think this is the same issue, since one is UmbracoEnsuredPage (WebForms) while the other is UmbracoAuthorizedController (MVC). I can't tell for sure though whether it derives from the same error "under the hood" somewhere.

Kenn Jacobsen 02 Mar 2015, 21:05:12

Possibly related to U4-6332?

Shannon Deminick 02 Mar 2015, 21:52:05

Hi all,

Routing for the back office has been this way for quite some time, see:


In order for the forms auth to kick in for the UmbracoModule it needs to detect that it's a back office route, there's several reasons for this as mentioned in that blog post (since version 7.0.2):

With the new UmbracoApiController there is no way for us to tell if the controller is being used for the front-end or the back-office. Without knowing if the request is for the front-end or back-office, this causes problems with how we authenticate Users and Members and also causes problems with how we assign the Culture to the current request for a given User or Member.

So for example, if you are logged in as both a User (back office) and a Member (front-end), it is impossible to set the culture for the request or know what IPrincipal to assign to the request since both would authenticate, therefore we need to determine if it's a back office vs front-office request and we can only do that by detecting the route. Back office requests need to be inside of Umbraco which makes perfect sense since that is the back office.

I think there's different issues at play here however as pointed out by Anders which I'll look in to this week.

Anders Bjerner 02 Mar 2015, 22:57:56

Did some more testing with WebForms. As Kenn mentioned in his issue, the problem seems to revolve around UmbracoContext.Current.Security.CurrentUser for some being null :'(

Ali Sheikh Taheri 03 Mar 2015, 09:44:18

Hi Shannon,

According to the article, that should have been a breaking change from 7.0.2 however I only have the same problem in Umbraco version 7.2.2 ? that doesn't make sense !

Should I create a new issue for it?

Thanks Ali

Anders Bjerner 03 Mar 2015, 10:13:03

@Shandem I did some more testing, and found the following:

  1. Creating an .aspx page in /App_Plugins/Whatever, UmbracoContext.Current.Security.CurrentUser will be null.

  2. Creating an .aspx page in /umbraco/Whatever, UmbracoContext.Current.Security.CurrentUser is an instance of Umbraco.Core.Models.Membership.User.

So it works when in the umbraco folder, but not in App_Plugins.

Shannon Deminick 03 Mar 2015, 12:38:57

There's seems to be some mixed issues on this issue.

@abjerner : Webforms back office pages not under /umbraco, did that work in 7.2.1?

@ateetaheri : That change was made in 7.0.2. I have no idea what your project does or how your page is routed, can you provide more details and steps to reproduce please. You say you don't get this in 7.2.0, but does it work in 7.2.1, but then you say just above that you have the same problem in 7.2.0 ... ??

Ali Sheikh Taheri 03 Mar 2015, 12:43:56

I am going to create a new issue then and I will explain it there.

Anders Bjerner 03 Mar 2015, 12:45:07

@Shandem Yes - it has worked perfectly until 7.2.2. I think we have used it in the Analytics package ever since the package was released in December 2013.

I think the word back then was to ship all files for your plugin under /App_Plugins/ rather than under /umbraco/ as we used to in v6.

Anders Bjerner 03 Mar 2015, 21:17:22

@Shandem If we are eager to release a new version of the Analytics package (my own Skybrud.Social for Umbraco has the same issue) and can't wait for 7.2.3 for this to be fixed, do you have a recommended approach?

Simply move the .aspx files to a sub folder under /umbraco/. Feels a bit dirty though to place files in the /umbraco/ folder ever since we've learned to place files under /App_Plugins/.

The old umbraco.BasePages.UmbracoEnsuredPage is deprecated, but still does the job. I can't find anything on when it will be removed. Is it safe to assume it will stick around for at least some time?

Sorta mimic the logic behind UmbracoContext.Current.Security.CurrentUser? Is this possible? The following seems to work, but not sure whether there are any fallpits:

HttpContextBase wrapper = new HttpContextWrapper(HttpContext.Current);

UmbracoBackOfficeIdentity user = wrapper.GetCurrentIdentity(true);

Thanks for your efforts ;)

Shannon Deminick 05 Mar 2015, 05:22:16

@abjerner I've run a bunch of tests now and the problem is due to the fix for this issue http://issues.umbraco.org/issue/U4-6093 and a change it validating if a user is logged in.

You should be able to put this code at in your webforms OnPreInit before you call anything else:

var http = new HttpContextWrapper(Context);
var ticket = http.GetUmbracoAuthTicket();
http.AuthenticateCurrentRequest(ticket, true);

which should solve this issue. I'll update the UmbracoEnsuredPage classes with this logic for 7.2.3. Please let me know if that works for you.

In 7.3.0 we'll be incorporating ASP.Net Identity. This is going to generally auth by request path for the back office. I'll check to see if we can still auth webforms that exist outside of /umbraco/ request path (probably possible but will be interesting). However, there is something you can do currently with webforms which is quite nice and that is to custom route your webforms pages using normal routing.

Here's a some docs on that: https://msdn.microsoft.com/en-us/library/vstudio/dd329551%28v=vs.100%29.aspx

If you want your webforms to just work normally without route tokens, you can just not specify them. This might be a very easy way to make your webforms route through /umbraco/ but have your physical files elsewhere. This would also make it easier for firewall people to be able to lock down back office routes.

Shannon Deminick 05 Mar 2015, 05:53:22

fixed in 88ae95150edcd36231e68e0a5cbb8cde6cf26ea0

Anders Bjerner 05 Mar 2015, 22:47:03

@Shandem Yup, that seems to do the trick. Thanks for your help ;)

Shannon Deminick 05 Mar 2015, 23:58:37

Ok great, thx for letting me know:)

Thomas Kardaridis 15 May 2015, 20:42:45

I am facing the same problem but instead of aspx page i am using an UnmbracoAuthorizedController which returns a view. Can anyone help how to resolve the issue?

Shannon Deminick 18 May 2015, 01:59:33

I've replied to you here: http://issues.umbraco.org/issue/U4-6352

Priority: Major

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal


Backwards Compatible: True

Fix Submitted:

Affected versions: 7.2.2, 7.2.8

Due in version: 7.2.3


Story Points: