#1396 Lost context `User` in `MultiplexingMiddleware`

[Ugway77]

Fixes #1396

• #1396

Current Behavior

If using RouteClaimsRequirement then Claims are lost after passing MultiplexingMiddleware because it creates new HttpContext and does not copy User property.

Proposed Changes

• Copy User property when creating new HttpContext in MultiplexingMiddleware and, maybe, use source HttpContext and simplify code if only one downstream route found.

[Kation]

Link https://github.com/ThreeMammals/Ocelot/issues/1396

[raman-m]

Please do the following:

• Merge PR 1
• Rebase feature branch onto develop
• Resolve all merge conflicts

[raman-m]

@Ugway77 Hi Алексей! I thought you needed a help to resolve merge conflicts. 😉 The feature branch has been rebased onto ThreeMammals:develop successfully! Welcome to code review!

---

If you are going to contribute in future... I see that develop branch in your fork is old. Could you Sync fork please? So, the develop branch will be updated with all top commits! Could you add me as collaborator to your forked repo please? I will update develop branch.

---

Is this PR related to some issue in backlog?

[raman-m]

@Kation commented on May 28, 2021:

• #1396

Could you review the current solution and confirm please that the solution fixes #1396 (your user scenario)? Thanks you!

[raman-m]

@tmkhan @aliprogrammer69 @andrei-manulife As a participant in the discussion of issue #1396, Could you review the code please? Your verification of the solution is also welcomed!

[ggnaegi]

@raman-m @Ugway77 doesn't seem to respond, could we create another PR instead? I would like to tackle this issue for the annual release, and then, in a second step, the modifications in the Multiplexing Middleware. Thanks!

[raman-m]

@ggnaegi I will take care of this PR having assigned High priority Will start development right after merging #1963

...doesn't seem to respond, could we create another PR instead?

We have feature branch: Ugway77:fix_contextuser_lost_after_multiplexing We can reuse the branch, no need to create separate one. But sure, we could have some pair programming :wink:

[raman-m]

Information

Class: Ocelot.Multiplexer.MultiplexingMiddleware Assembly: Ocelot File(s): src/Ocelot/Multiplexer/MultiplexingMiddleware.cs

---

Line coverage: 54.1% (+1.0) Branch coverage: 42.3% (+3.9)

[raman-m]

@ggnaegi commented

Please, review and I'm going to merge. Because this is system core upgrade in multiplexer I'm not sure on updating docs. Should we write in docs that current User is multiplexed for the rest of pipeline middlewares?

1st, User can setup Ocelot app authentication (app instance access) in own way, so seems this is out of the scope of our responsibility, but we forward User property when multiplexing.

2nd, downstream route can authenticate if AuthenticationProviderKey exists, and User property of app instance (current request) will be overwritten by new auth result of downstream after multiplexing.

3rd, I paid my attention to entire Ocelot pipeline. Our lovely MultiplexingMiddleware https://github.com/ThreeMammals/Ocelot/blob/d54836d51f6ea29a2013967e3649a23e19db28b3/src/Ocelot/Middleware/OcelotPipelineExtensions.cs#L59 is defined before AuthenticationMiddleware: https://github.com/ThreeMammals/Ocelot/blob/d54836d51f6ea29a2013967e3649a23e19db28b3/src/Ocelot/Middleware/OcelotPipelineExtensions.cs#L96 So, because of that pipeline middleware order we can't get authenticated user of current request when multiplexing. But in theory we can setup Ocelot to authenticate each request (per app instance) and forward this user. But it is impossible because of pipeline design. Look at my acceptance test: it has a lot of coding hacks to finally get auth user of the request. Also, seems Ocelot breaks regular ASP.NET conveyor and my custom auth setup in AddMvcCore have failed (per app instance), https://github.com/Ugway77/Ocelot/blob/fix_contextuser_lost_after_multiplexing/test/Ocelot.AcceptanceTests/AggregateTests.cs#L560-L567 and I have to authenticate manually right in the place. This is bad. I expect that other ASP.NET middlewares are broken too: it will be impossible to setup their DI services.

[ggnaegi]

@raman-m commented on Feb 21

It is why I decided to refactor the multiplexer: The code is very difficult to read and to understand. As soon as we are done with this PR, I'm going to rebase the Multiplexer-PR. I'm going to review the code tomorrow!