Das mag für dich alles ironisch und witzig sein, für mich ist es das nicht.
In der Regel bekomme ich eine Anforderung zur Umsetzung und schaue dann, wie und mit was man das am besten umsetzen könnte. Ich kenne nicht jede MS-API, nicht jede Doku, nicht jede Library und nicht alle best practices, schon gar nicht im Detail. Die Entwicklung ist mittlerweile so schnell, dass ich nicht mehr hinterher komme. Ich habe den Überblick verloren. Ich kann mich mit den Dingen erst dann beschäftigen, wenn ich sie auch aktiv nutzen will/muss. Und das dauert. Irgendwann hat man sich durch Erfahrung irgendwo eingearbeitet, und dann ist es ruckzuck obsolet und durch x andere Dinge ersetzt. Ja, das ist in der IT so. Aber ich bin nun mal nur ein Mensch und habe nur begrenzte Zeit.

Ja, ich habe mich anfangs recht knapp gehalten. Einfach aus dem Grund, weil nach meiner Erfahrung lange ausführliche Beschreibungen nicht gelesen werden. #TLTR oder #TLDR.

Du hast ne Microsoft ASP.NET Core Lib verwendet, die für Mulit Platform gedacht ist und auf die Windows Registry zugreift?
Bezweifle ich.

Auch hier wusste ich nicht, dass es eine Mulit Platform Kennzeichnung gibt. ASP.NET Core ist ein plattformübergreifendes Framework. Daher habe ich naiv gedacht, auch die Librarys für ASP.NET Core wären plattformübergreifend. Vor allem wenn sie von MS kommen.
Während der Entwicklung ist nichts aufgefallen, weil ich unter Windows entwickle. Sobald mein Service dann in einem Docker-Container lief, hat es geknallt. Seit dem wäge ich genau ab, ob es mir das Risiko wert ist. Ich nutze ja selten die komplette Funktionalität einer Library.

Sei's drum, ich glaube unsere Gags und Grundsatzdiskussionen sind ein anderes Thema. Danke für deine Hilfe.

Bitte entschuldige meine Unwissenheit.

Was Du mit den Code-Schnippseln hier willst: keine Ahnung.
Aus dem Zusammenhang gerissen und einfach mal gepostet? Ja, dann kommt invalid Token bei raus 🙂

Ich kenne das so, dass man bei einer Frage in einem Forum erst mal das Problem beschreibt und was man bereits gemacht/ausprobiert hat.
Ich habe viele Tutorials ausprobiert wie das hier und ähnliche. Je nach Tutorial war mal die neue und mal die alte URL, wobei ich nicht erkennen konnte, welche davon die Aktuelle ist. So oder so, ich bekomme bei beiden URLs das gleiche Ergebnis.

Meine Code-Schnippsel sehen so aus, wie in dem Tutorial weiter oben. HTTP-Aktion + URL + Header. Kann ja sein, dass eines davon falsch ist.

Ebenso kannst Du einfach das Microsoft Identity SDK verwenden.

Am liebsten würde ich tatsächlich plain REST verwenden. Ich habe mit den Microsoft-SDKs schlechte Erfahrung gemacht. Eine davon war ein ASP.NET Core-Library. Sie versuchte auf die Registry zu zugreifen. Da mein Service unter Ubuntu gehostet wird, gab's die natürlich nicht. Solche "Überraschungen" möchte ich gerne vermeiden.

Je nachdem was Du machst, kann es auch sein, dass Du aufgrund der Sicherheitsleveln (zB Full Access) den Weg über ein Zertifikat gehen musst.

Hmm, das wäre schlecht. Mein Service ist eine Middleware, die meist on-prem läuft. Sie bietet eine REST-API über die man z.B. Bibliothekseinträge und die dazugehörigen Dateien anfordern kann.

Bisher lief das so:
Ein Client sendet einen HTTP-Request zu meiner Middleware. In diesem Request ist unter anderem die URL zum Sharepoint-Tenant (z.B. https://myTenant.sharepoint.com), Sharepoint Benutzer Credentials (Benutzername und Passwort) und die ID einer Bibliothek/Liste. Die Middleware hat dann mit den Credentials einen Cookie angefordert und dann diese Anfrage inkl. Cookie dann an Sharepoint weiter geleitet, eine Antwort von Sharepoint bekommen und diese Antwort dann aufgearbeitet an den Client weiter geleitet. Das funktioniert auch wunderbar.

So soll es in Zukunft laufen:
Die Funktionalität von oben soll erhalten bleiben. Lediglich die Art der Authentifizierung soll von Basic auf OAuth2 umgestellt werden. Da es sich um einen Dienst, der auf irgendeinem Server läuft, handelt, darf nicht der Dialog mit der Anforderung der Zugriffsrechte erscheinen. Das muss vorher korrekt im Azure-Portal konfiguriert sein. Auch hier bin ich mir unsicher.
Sollte ein Zertifikat notwendig sein, müsste der Client dieses bei jedem Request mit senden. Das würde ich auch gerne vermeiden.

Die Aktionen, die meine Middleware auf Sharepoint durchführt:

• Lesen der Schemata von Listen/Bibilotheken
• Lesen der Schemata von Content-Types
• CRUD-Operationen auf Bibliothekseinträge
• Hoch- und Runterladen von Dateien in/aus diesen Bibliothekseinträgen

Mir ist jetzt auch noch was anderes aufgefallen.
Wenn ich den bisherigen Weg gegangen bin (mit den Credentials), habe ich folgende URL aufgerufen um eine Bibliothek zu holen:

https://myTenant.sharepoint.com/_api/web/lists(guid'{listId}')

Kann ich das so weiter nutzen, oder muss ich jetzt die Graph-API verwenden?

https://graph.microsoft.com/sites/{siteId}/lists/{listId}

Ich habe das jetzt mal mit der Graph SDK und diesem Beispiel-Code (etwas erweitert um das Holen der Spalten einer Liste) erfolgreich ausprobiert. Aber das JSON-Objekt hat eine andere Struktur, als bei meinem bisherigen Weg mit Credentials. Kann man OAuth2 nur mit der Graph-API verwenden, oder geht das auch über die bisherige Sharepoint REST API?

Ich habe schon so einige Tutorials ausprobiert, aber nichts hat funktioniert.
Ich versuche mich per OAuth2 und REST an Sharepoint zu authentifizieren.

POST "https://login.microsoftonline.com/{targetSharepointApi.TenantID}/oauth2/token"

FormUrlEncodedContent:
client_id=myId&
client_secret=mySecret&
grant_type=client_credentials&
resource=https://myTenant.sharepoint.com

(habe es auch noch zusätzlich mit scope=https://myTenant.sharepoint.com/.default versucht).

Bekomme daraus ein JSON-Objekt in dem unter anderem auch ein accessToken enthalten ist. So weit, so gut.
Versuche ich dann aber irgendwelche Ressourcen aufzurufen (Authorization=Bearer {accessToken}), bekomme ich ein 401 zurück mit der Meldung "Unsupported app only token".
Ich habe das Gefühl, da fehlt noch ein Schritt.

App ist im Azure-Portal angelegt, Secret ist angelegt und die App hat (erst mal) weitreichende Berechtigungen.
Kann mir bitte jemand auf die Sprünge helfen?

Der frühere Standard RFC2047, der ISO-8859-1 erlaubte, wurde durch RFC7230 abgelöst.

Der erklärt einiges.

ASP.NET Core an dieser Stelle ist also korrekt implementiert; der Fehler liegt beim Absender.

Habe es zunächst über Swagger ausprobiert, aber da kann man ja eingeben, was man will. Postman lässt tatsächlich (nur) ISO-8859-1-Zeichen zu. Wenn man was anderes eingeben will, meckert Postman. Das Paragraphen-Zeichen lässt er zu. Daher dachte ich nicht daran, dass es da noch weitere Einschränkungen gibt.

Deswegen wars wichtig zu wissen, mit welcher ASP.NET Variante (und nicht der Produktfamilie selbst) Du arbeitest.
WebAPI war früher ein eigenes Modul; ist heute nur noch Marketing-Begriff weil es einfach Teil von ASP.NET MVC ist.

Ich blicke bei den Begrifflichkeiten nicht mehr durch.

Der interessante Teil hier ist (ich habs selbst noch nicht gebraucht)

  
"RequestHeaderEncoding": "utf-8"  
  

  
private static IHostBuilder CreateHostBuilder(string[] args) =>  
    Host.CreateDefaultBuilder(args)  
        .ConfigureWebHostDefaults(webBuilder =>  
        {  
            webBuilder.UseStartup<Startup>()  
                      .ConfigureKestrel(kestrel =>  
                      {  
                          kestrel.RequestHeaderEncodingSelector = _ => Encoding.Latin1;  
                      });  
        );  
  

Habe ich ausprobiert, aber das Paragraphen-Zeichen wird trotzdem nicht korrekt dekodiert. 🙁

Wenn man ein neues Projekt diesen Typs anlegt, nennt sich das "ASP.NET Core-Web-API". Habe zwei Projekte, .NET Core 3.1 und .NET 6.0.
Methode im Controller sieht so in der Art aus:

[HttpGet]
[ServiceFilter(typeof(TraceReqestAttribute))]
[Produces(ContentTypes.APPLICATIONJASON)]
public async Task<ActionResult<MyEntity>> Get([FromHeader][Required] string id, [FromHeader][Required] string testString)
{

}

Problem ist hier das Argument "testString".

Ich habe es auch mit einem ServiceFilter versucht, um den Parameter möglichst früh abzugreifen:

    public class TraceReqestAttribute : ActionFilterAttribute
    {
        public override void OnActionExecuting(ActionExecutingContext context)
        {
            if (context.ActionArguments?.Count > 0)
            {
               KeyValuePair<string, object>? parameter = actionArguments.FirstOrDefault(x => x.Key.ToLowerInvariant().Equals("testString"));
               _testString = parameter?.Value.ToString();
            }
            base.OnActionExecuting(context);
        }

Leider das gleiche Ergebnis.
Wenn ich an den Parameter kommen würde, bevor er dekodiert wird, könnte ich ihn selbst korrekt dekodieren. Das scheint aber schon vorher zu passieren, denn parameter.Value ist zwar vom Typ object, darin steckt aber schon ein String.

Ich habe das Problem, dass ich in meiner WebAPI in einem Request einen Header-Parameter bekomme, der das Paragraph-Zeichen (§) enthält. Dieser wird nicht korrekt angezeigt. Stattdessen sieht man �.
Eigentlich können HTTP-Header ISO-8859-1-Zeichen enthalten. Die WebAPI kann aber anscheinen nur ASCII decodieren. Oder kann man das irgendwie konfigurieren?

Wirste so ohne Mounten vermutlich nicht hinbekommen.

Alles klar, danke.
Dachte ich mir schon, werde jetzt nach einer anderen ganz Lösung suchen.

Ich arbeite an einem Dienst, den ich in ASP.NET Core entwickle. Dieser Dienst wird unter Ubuntu gehostet.

Nun muss ich auf UNC Pfade zugreifen, was an sich kein Problem ist. Aber nur so lange bis man auf UNC Pfade mit Credentials zugreifen möchte. Ich weiß zwar, dass das mit dem Einbinden von Windows-API-Funktionen advapi32.dll geht, aber die habe ich unter Ubuntu nicht.

Eine Besonderheit ist auch, dass ich diese UNC-Pfade nicht unter Ubuntu mounten kann, da sie irgendwann zur Laufzeit bekannt werden. Und es können beliebig viele sein.

Weiß jemand eine Lösung?

Das ist mittlerweile eine sehr weit verbreitete und übliche Anforderung.

Ich vermute, das wird sich in der Zukunft immer mehr Richtung Cloud verlagern, aber bis dahin müssen wir diese zwei Welten versuchen zu vereinen. Fühlt sich alles irgendwie als Notlösung an.

Warum kein standardisierten Weg nehmen?

Ich weiß es auch (noch) nicht, sitze hier sozusagen zwischen den Stühlen. Ich muss mir das nächsten Jahr mal genauer anschauen.
Danke schon mal für deine Hilfe.

Sorry, dass ich mich erst jetzt melde, Weihnachtsfeier und so... 😁

Sowas hab ich fast schon befürchtet: und wäre ein riesen Fehler.

Ja, leider habe ich da nicht die Entscheidungsgewalt. Ist aber auch ein etwas ungewöhnlicheres Problem, weil es um eine Art Hybrid-Cloud geht, also zum Teil bei Azure gehostet, teilweise on-prem.

Willst Du trotz der Gefahren, diese Richtung weiter gehen, dann lös das ganze über RoutePrefixes.
Dazu gibt es auch ein GitHub Repository, wo Du Dirdas Verhalten abschauen kannst

>
Dort gibts auch noch ein Sample mit der Swagger Integrierung. Prinzipiell bekommst damit Dein Vorhaben geschenkt.

Ich habe mir das angeschaut, muss aber ehrlich zugeben, ich steig da nicht wirklich durch bzw. weiß nicht so recht, was davon relevant für mich wäre. Wir grübeln derzeit an verschiedenen Lösungsansätzen, aber so richtig gut gefällt uns noch nichts davon.

Danke. Die machen wir jedes Jahr, teilweise sogar mehrfach. Ist ein altes Rezept von meiner Mutter, die es vermutlich von ihrer Großmutter hat. Für mich immer ein Ausflug in meine Kindheit. Und Junior liebt sie auch.