Wie handhabt Ihr bedarfsabhängige Endpunkte?

Der Titel klingt etwas wirr, hier die Erklärung:

Im Laufe der Entwicklung, greift Eure App ja auf verschiedene APIs oder SQL Connections zu, oder nutzt verschiedene Credentials, abhängig von Eurem  aktuellen Development-Status. Also Release, oder Debug,  oder Debug mit Live Daten, oder Release mit Debug Daten, usw...

Wie handhabt Ihr diese Situation?

In meinen Projekten nutze ich dafür die BuildConfiguration in VS. Ich habe x Build Konfigurationen und entsprechend der gerade ausgewählten, werden dann im DatabaseController, oder im APIController, oder wo auch immer die entsprechend benötigten Credentials/Strings geladen:

#if DEBUG_LIVE
        private static string APIString = Data.Const.Release_API;
#endif
#if DEBUG_TEST
        private static string APIString = Data.Const.Debug_API;
#endif

Gibt es da einen besseren/schnelleren/schöneren Weg?

Danke im Vorraus!

Kriz

• Regel 1: Wann immer möglich keine Credentials verwenden, sondern sowas wie Managed Identity (gibts auch ausserhalb von Azure).
• Regel 2: Credentials haben niemals was im Projekt oder Code zu suchen, sondern wenn überhaupt über Umgebungsvariablen.
  In ASP.NET dann verfügbar zu machen über den Option Pattern.

Hallo Kriz,

schau dir dazu Configuration an und dazu auch Environment.

Damit bleibt der Code "schön" (ohne die Präprozessor-Direktiven) und jeweiligen Einstellungen (ConnStrings, etc.) können in Abhängigkeit von der Umgebung (Environment) geladen werden.
So ist auch lokales Testen, Testen in CI, Staging, Produktion, etc. einfach und ohne Änderung im Code möglich.

mfG Gü

Erstmal danke für die Antwort!

Ich hätte dazu schreiben sollen, dass es um eine Xamarin App geht, dort gibt es den Luxus von appsettings.json in Verbindung mit Enviroments leider nicht. Zwar gibt es ein NuGet (Mobile.BuildTools), aber das wirft mehr Fehler, als dass es hilft und wird auch nicht mehr aktualisiert.

Clients wie Xamarin, Desktop etc… gelten als vertrauensunwürdige Umgebungen.

Hier sollten niemals Credentials in der App sein. Das ist alles auslesbar.

Einzige sichere Möglichkeit ist den User über Tokenverfahren zu authentifizieren und den Token an der API zu validieren.

Solch ein Client sollte immer über eine API - in der Regel Backend for Frontend-Prinzip - umgesetzt sein, niemals direkt auf Datenbanken oder sonstige APIs.

Das ist ein ganz wichtiger Grundsatz in Sachen Sicherheit.

Dies ist in diesem Fall auch so, alle Kommunikation geht über einen API Server und dann erst weiter zur DB.

Mir ging es darum, dass ich verschiedene APIs für verschiedene UseCases habe (Releease, Debug, Debug mit Live Daten, usw). Anhand der ausgewählen Build Konfiguration nutze ich dann die entsprechende API. Meine Frage war nun ob es in diesem Fall einen einfachreren/besseren Weg gibt.