feat(backend): Authentication

[cerphilipp]

Soweit letzte Woche vorgestellt für Organisation und Service Ebene. Falls Formatierungs einfach gleich einen autoformat commit machen, weiß noch immer nicht wie das in VS geht.

[MarkusJx]

Soweit letzte Woche vorgestellt für Organisation und Service Ebene. Falls Formatierungs einfach gleich einen autoformat commit machen, weiß noch immer nicht wie das in VS geht.

https://stackoverflow.com/a/5755979

Echt jetzt...

[MarkusJx]

Das funktioniert nicht. Du musst deinen code schon testen. Hast wohl vergessen das zu registrieren in Default[MODULE_NAME]Module. Beispiel:

builder.RegisterType<ServiceService>()
      .As<IServiceService>()
      .InstancePerLifetimeScope();

Details

``` System.InvalidOperationException: Unable to resolve service for type 'ServiceReleaseManager.Api.Authorization.IServiceManagerAuthorizationService' while attempting to activate 'ServiceReleaseManager.Api.Endpoints.OrganisationRoles.Create'. at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.GetService(IServiceProvider sp, Type type, Type requiredBy, Boolean isDefaultParameterRequired) at lambda_method785(Closure , IServiceProvider , Object[] ) at Microsoft.AspNetCore.Mvc.Controllers.ControllerActivatorProvider.<>c__DisplayClass7_0.b__0(ControllerContext controllerContext) at Microsoft.AspNetCore.Mvc.Controllers.ControllerFactoryProvider.<>c__DisplayClass6_0.g__CreateController|0(ControllerContext controllerContext) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker) at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger) at Microsoft.AspNetCore.Authorization.Policy.AuthorizationMiddlewareResultHandler.HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult) at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext) at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider) at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context) ```

[MarkusJx]

Das ganze sollte auch ins Core projekt, wenn ich das so richtig verstanden habe @DevNico

[cerphilipp]

Die NotFounds sind mit absicht. Standard. Weil nicht authorisierte User sollten nicht wissen ob eine Resource exstistiert. Das mit der fehlenden DI war aus versehen ich wollte gestern unbedingt noch pushen und hab ein paar Änderungen reverted, hab dann noch schnell die Tests ausgeführt und habs übersehen. Das mit in Core wird nicht funktionieren, weil ASP-NET Abhängigkeiten gebraucht werden.

[MarkusJx]

Die NotFounds sind mit absicht. Standard. Weil nicht authorisierte User sollten nicht wissen ob eine Resource exstistiert.

Ich will jetzt kein Arsch sein aber ich will hier wirklich der Arsch sein, aber: Schauen wir uns mal als beispiel den CREATE für organizationUsers an. Wenn wir, so wie ich das beschrieben habe, die rechte prüfen, bevor wir in der Datenbank schauen, ob die Rolle oder die Organisation existiert, erfährt ein Potenzieller Angreifer nicht, ob die Organisation oder die Rolle existiert. Und ob der Endpunkt existiert, ja, das darf glaub ich jeder wissen (vorallem bei public APIs).

GetById sieht hier ähnlich aus, jeder Nutzer ohne Rechte erhält code 401, egal, ob der Nutzer existiert oder nicht. Angemeldete Nutzer mit entsprechenden Rechten erhalten dann code 404, sollte der Nutzer nicht existieren.

Der standard mit der .net auth scheint auch eher immer code 401 zurückzugeben, sollte ein endpunkt nicht existieren, das möchte ich hier auch noch in den Raum werfen.

Letztendlich ist das egal, ich finde 401 definitiv informativer (zumindest fürs Entwickeln), in der finalen Anwendung könnte da auch alles zurückgegeben werden, ein Endnutzer befasst sich sowieso nicht mit den http codes.

Ich würde das ganze also mal @DevNico entscheiden lassen, ob wir 404 oder 401 bei nicht ausreichenden Rechten zurückgeben wollen

[MarkusJx]

Wenn das mit dem Verschieben in Core wirklich nicht klappt, dann glaub ich dir das einfach mal so, das Template ist irgendwie kacke, aber das wissen wir inzwischen ja schon

[cerphilipp]

Ja ok über die Return codes kann man ja reden. Zu dem im Core, dass liegt nicht an dem Template es liegt an der ASP.Net Authorization, für die man ASP.Net braucht

[DevNico]

Wegen den Status codes bin ich für 404, so kann man nicht iterieren um herauszufinden wie groß z.b. die user base ist

[DevNico]

Wenn Auth ne dep auf ASP.Net hat kanns im api projekt bleiben