Estoy usando una aplicación de ensamblaje web blazor que no está alojada en ASP Net Core para un sitio web personal. Este sitio web está integrado con Contentful CMS que requiere una clave de API, una clave de vista previa y una identificación de espacio. Actualmente los almaceno dentro de mi propio appsettings.json en www/root y accedo a ellos inyectando IConfiguration en mi servicio y luego accediendo a los valores a través del método GetSection.
Toman la forma:
"DeliveryApiKey": "A", "ManagementApiKey": "not used", "PreviewApiKey": "B", "SpaceId": "C",```Esto está bien para ejecutarlo localmente, pero después de investigar un poco en línea, estas claves serían legibles y visibles para los usuarios si se implementan y se descompilan los dlls.
¿Cuál es la mejor manera de almacenar claves API con una aplicación de ensamblaje web blazor? Me pregunto si debería crear un proyecto blazor alojado en asp net core que me daría un servidor y un proyecto compartido, pero si tuviera que implementarlo, no estoy seguro de si eso funcionaría con acciones de github y netlify si tuviera que implementar únicamente el lado del 'servidor' de mi proyecto. ¿Cuál es el mejor curso de acción?
*Editar, así es como uso esas claves para acceder al contenido de CDA. Esta es la forma basada en la documentación.
{ var apiKey = _configuration.GetSection("ContentfulOptions").GetSection("DeliveryApiKey").Value; var previewKey = _configuration.GetSection("ContentfulOptions").GetSection("PreviewApiKey").Value; var spaceid = _configuration.GetSection("ContentfulOptions").GetSection("SpaceId").Value; var httpClient = new HttpClient(); var client = new ContentfulClient(httpClient, apiKey, previewKey, spaceid); return client; }En general, si algún secreto (clave API, contraseña, etc.) está disponible en el cliente (navegador web, aplicación de escritorio, etc.), independientemente del medio (incluido Blazor WASM), es solo una cuestión de persistencia antes de que dicho secreto sea comprometido. El cifrado es de poca ayuda, porque aún necesita la versión real de texto sin cifrar en algún punto del cliente para facilitar el acceso.
Recomiendo encarecidamente mantener cualquier información confidencial del lado del servidor. En el caso de una aplicación Blazor WASM, esto significa una API web secundaria, etc., accesible desde el cliente (sí, sigue siendo un riesgo de seguridad, pero mucho más típico: las API seguras son un problema resuelto, con Identity Framework, por ejemplo). y técnicas similares).
Todavía recomendaría usar un servicio Key Vault para cualquier cosa realmente confidencial, incluso para el acceso del lado del servidor (de todos modos, este es el caso de uso principal para un almacén de claves): es una práctica mucho mejor que almacenar las claves localmente, integradas en la aplicación, comprometido con GitHub, etc.
Eche un vistazo a este video (prometo que no gano una comisión por las ventas de Azure, simplemente creo que es una gran solución). El video presenta una aplicación Blazor Server, pero la técnica se adapta fácilmente a una aplicación Blazor WASM que llama a una API web.
Volviendo a dar una respuesta después de pensar en el problema. Decidí crear una API web para este proyecto y escribir servicios para consumir lo que hace el trabajo sucio al consultar ContentfulCDA. Todo lo que tengo que hacer es deserializarlo en lo que quiera. Esta parece ser la mejor manera de avanzar, ya que las claves de API serían visibles en el lado del cliente a través de appsettings.json.
Además, aparentemente appsettings.json en los proyectos blazor wasm no puede acceder a las variables ambientales ya que no están expuestas al navegador, por lo que mi idea de usar EV no funciona. Por lo tanto, la API web es la mejor manera de avanzar, y Azure Key Vault sería el siguiente paso para asegurar esas llaves.
Tudor