We have moved to GitHub Issues
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:
UmbracoEnsuredPage(the one in
/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.
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?
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.
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:
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.
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)
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.
Possibly related to U4-6332?
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.
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
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?
@Shandem I did some more testing, and found the following:
Creating an .aspx page in
UmbracoContext.Current.Security.CurrentUser will be null.
Creating an .aspx page in
UmbracoContext.Current.Security.CurrentUser is an instance of
So it works when in the
umbraco folder, but not in
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 ... ??
I am going to create a new issue then and I will explain it there.
@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.
@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?
/umbraco/. Feels a bit dirty though to place files in the
/umbraco/folder ever since we've learned to place files under
umbraco.BasePages.UmbracoEnsuredPageis 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?
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 ;)
@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.
fixed in 88ae95150edcd36231e68e0a5cbb8cde6cf26ea0
@Shandem Yup, that seems to do the trick. Thanks for your help ;)
Ok great, thx for letting me know:)
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?
I've replied to you here: http://issues.umbraco.org/issue/U4-6352
Assignee: Shannon Deminick
Backwards Compatible: True
Affected versions: 7.2.2, 7.2.8
Due in version: 7.2.3