Authorization

[Cooksauce]

In the replicated service scenario, is this going around ASP.NET Core authorization? It appears that when a computed value is re-computed, it wouldn't be sent through the normal authorization handlers that a normal request would go through - am I interpreting that incorrectly?

[alexyakunin]

@Cooksauce yes, you're interpreting this correctly - which is why samples actually don't rely on ASP.NET Core authorization. You can use it in controllers, but you're totally right - when such values are updated, most likely the update requests will be routed via WebSocket channel. The only reason update may go through controller is when the client loses the computed value (i.e. client-side IComputed describing the call gets garbage collected).

[alexyakunin]

For the note, it's intended that you can't rely on ASP.NET Core authorization:

1. Authorization is technically a computation triggering either an exception or a regular flow. And if so, it has to be a part of Compute Services too - otherwise e.g. a permission change may not trigger the invalidation automatically.

2. There are a two main reasons ASP.NET Core Web API support was implemented in Fusion first:

• RESTful APIs are still the most popular ones, and the way Fusion "integrates" with ASP.NET Core implies you can call such APIs from both Fusion-aware and regular clients. In other words, this approach allows you to expose the RESTful API for any Fusion service ~ for free.
• Any externally callable service needs a robust argument validation, and ASP.NET Core provides one.

BUT it was always implied that at some later point more efficient protocols will be added, and thus we can't have any strong dependencies on whatever is available in ASP.NET Core.

This is why Fusion introduces its own Session type, and even its own User - if you do permission checks w/ Fusion, it's much better if such checks rely on Fusion-backed services too, so that changes related to authorization are applied instantly as well. Because if they aren't, you're risking to expose the old data that passed some permission checks once for indefinitely long period. Remember, Fusion "thinks" that any result stays the same unless it or one of its dependencies is invalidated!

[alexyakunin]

@Cooksauce added a bit more details on that - hopefully this explains why it's done like this.

IMO it's not a compromise, btw - what's done is actually the most robust way to do this.

[alexyakunin]

Closing this issue - @Cooksauce please feel free to add more questions here or on Discord.