U4-4010 - Member and user session gets mixed

Created by Per Ploug 08 Jan 2014, 22:40:55 Updated by Shannon Deminick 07 Jul 2015, 10:01:36

Relates to: U4-6796

Create a member, use the standard login partial view macro and log in with the member. The user will now get logged out of the back office with a session expired message - and cannot log back in.

The login returns status 200 but afterwards the /updatecheck returns 401: )]}',{"Message":"Authorizationhasbeendeniedforthisrequest."}

--

After the failed user login, a member still seems to be logged in on the website, and cms.businesslogic.member.Member.GetCurrentMemberId() returns the right value.

However, if you do the same call in a UmbracoApiController, it returns null, due to MemberShip.GetUser( ) returns null.

Cookies found:

UMB_UCONTEXT XSRF_TOKEN XSRF_V yourAuthCookie

Clearing cookies and logging in as the member again, fixes the issues with the api controller, but if I try to log in as a user, it fails again, and the user is still rejected

Comments

Shannon Deminick 09 Jan 2014, 02:27:59

I cannot replicate this.

  • I've logged in as admin in the back office
  • Then i log in as a member using the standard login partial view macro
  • I can still navigate in the back office as admin without issue and without errors
  • I can refresh the front-end page and I am still logged in as the member
  • I can log out of the back-end, the front-end member is still logged in
  • I can log out of the front-end, the back-end user is still logged in

Can you replicate this all of the time? If so maybe tried the latest revisions and see if some other fixes have fixed this.


Shannon Deminick 09 Jan 2014, 05:06:45

Perhaps you had v6 and v7 open at the same time running on localhost ? Then you'll get strange problems because the cookies are different but they have the same auth cookie name


Per Ploug 09 Jan 2014, 08:11:26

Hmm, nope, no V6 and cleared cookies several times.

This is the order I can replicate for sure:

  • Log out of backoffice, clear all cookies
  • log in on frontend as member
  • now try to login as the user on the backoffice, here it fails every time.

Second issue which is also consistently there:

  • Clear cookies
  • Log in as member
  • Call a UmbracoApiController with a call to cms.businesslogic.member.Member.CurrentMemberId()
  • this will work just fine
  • now try to log in as a user on the backoffice
  • this log-in will fail (its the issue above)
  • Now call the api controller again, the Member.CurrentMemberId() will now throw a null exception
  • Strange thing is, if I call a surfacecontroller with the same Member.CurrentMemberID() in, then it doest fail, but returns the correct member.

Only way to solve the above is to clear cookies and re-login as member.


Shannon Deminick 09 Jan 2014, 13:31:02

Hrm, I still cannot replicate this.

Can you attach the files that you are using for all of this?


Per Ploug 10 Jan 2014, 10:05:16

Okey, after looking into the updatecheckcontroller - the 1st issue is fixed - the class was missing the PluginController("umbracoapi") attribute - now it works fine, weird..

Tried adding: [MemberAuthorize(AllowType = "Member")] to the apicontrollers that failed with the current member ID, and while I'm logged into the backoffice, these refuse to authenticate, but if I log out, they work just fine.

Using latest 7.0.2 build.

The files is the level2 training site, will send you and email to the repo


Shannon Deminick 14 Jan 2014, 06:20:32

Hrm, still can't replicate this even without the change to the updatecheckcontroller, so not sure what the deal is there, in any case leaving the PluginController attribute can't hurt, all it does is change how it's routed.

Will see if i can reproduce the other stuff


Shannon Deminick 14 Jan 2014, 06:35:01

Ok cool, i can verify the other issue - which is probably causing you your initial issue as well.

This is an oversight and kind of a bad one at that, it was not taken into account that you'd have 2 users logged in at the same time. What is happening is the UmbracoModule performs the auth for the back office based on our custom forms auth cookie, we are then setting the current User/Thread principal object to the back office identity but unfortunately in .Net there can only be one User/Thread principal so it overwrites the default ASP.Net FormsAuth one that is set by the member.

Hrm, will have to get this fixed and/or think more about this.


Shannon Deminick 15 Jan 2014, 00:53:06

Ok, so the real cause is not setting the User/Thread principal object since this is only done when we detect a back office request so it wouldn't interfere with a member - but this is the problem = detecting a back office request because of the way that we route SurfaceControllers and UmbracoWebApiControllers since these both route via the /Umbraco/* path.

As it stands we would only be able to tell the difference between these routes as to whether they are back office or front-end routes:

Back office = /Umbraco/UmbracoApi/ /Umbraco/UmbracoTrees/

Front-end = /Umbraco/Surface/ /Umbraco/Api/

However, we have a problem for any package developers using UmbracoApiControllers or SurfaceControllers that use the [PluginController] attribute because when using this attribute you're routes will be /Umbraco/WHATEVERYOUWANT/ and with that there's really no way to tell if it is front-end or back end.

To fix this will require a slight breaking change in that we'd have to modify the routing behavior for UmbracoApiControllers by adding an additional attribute to these controllers: [IsBackOffice]

If this attribute is added, then we'd change the route to be: /Umbraco/BackOffice/*

Then we know for sure it's a back office request and we'd authenticate accordingly. By default the UmbracoAuthorizedApiController will have this attribute added.

So this breaking change would only affect any package developers currently creating stuff for v7 that requires their own API controllers that are also using the PluginController attribute who are not inheriting from the UmbracoAuthorizedApiController. I'm pretty sure that will be a very very few people or most likely nobody.


Priority: Major

Type: Bug

State: Fixed

Assignee: Shannon Deminick

Difficulty: Normal

Category:

Backwards Compatible: False

Fix Submitted:

Affected versions: 6.1.0, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 7.0.1

Due in version: 6.2.0, 7.0.2

Sprint:

Story Points:

Cycle: