Noticias Steam Machine SteamOS y Linux
Related Articles
Como desarrolladores, a menudo nos encontramos con obstáculos que ponen a prueba nuestra resiliencia y perspicacia técnica. En esta publicación de blog, compartiré mi experiencia al abordar dos desafíos que prevalecen en el desarrollo web moderno: problemas de intercambio de recursos entre orígenes (CORS) en .NET y perforación de accesorios en ReactJS. Mi viaje a través de estos obstáculos no solo ha mejorado mis habilidades para resolver problemas, sino que también me ha brindado conocimientos que creo serán útiles para otros desarrolladores. La lucha contra CORS en .NET Core Cross-Origin Resource Sharing (CORS) es una característica de seguridad que aplican los navegadores para evitar que sitios web maliciosos accedan a recursos y datos de otro dominio sin permiso. Mientras desarrollaba un backend .NET para mi proyecto, encontré errores de CORS que impedían que mi frontend de ReactJS obtuviera datos del servidor. Por ejemplo, puede aparecer un error como el siguiente: Comprender la causa raíz La política CORS estaba bloqueando mis solicitudes porque la fuente (que consta de un esquema, un nombre de host y un puerto) de la solicitud (mi aplicación React) no coincidía con el dominio del servidor. . Esta discrepancia activa un mecanismo de seguridad en los navegadores para protegerlos de posibles ataques de secuencias de comandos entre sitios. En general, los agentes de usuario agregan el encabezado de solicitud de Origen a: solicitudes de múltiples orígenes solicitudes del mismo origen excepto solicitudes GET o HEAD (es decir, se agregan a solicitudes POST, OPTIONS, PUT, PATCH y DELETE del mismo origen). Existen algunas excepciones a las reglas anteriores; Por ejemplo, si se realiza una solicitud GET o HEAD de múltiples orígenes en modo sin cor, no se agregará el encabezado de Origen. ¿Cómo funciona CORS? La solicitud de OPCIONES es una solicitud de verificación previa que forma parte de CORS. El mecanismo CORS que proporciona acceso de configuración a recursos compartidos. Sigue siendo aplicable a una página web que realiza una solicitud a otro servidor distinto al servidor de origen, es decir, el dominio, protocolo o puerto es diferente. Luego, el navegador verifica con el servidor si la solicitud está permitida o no. Si es así, el navegador ejecuta la solicitud. Por ejemplo, debajo del código se muestra una solicitud PUT a http://www.example.com/demo desde foo.example.com para ejecutar una solicitud de verificación previa – OPCIONES /demo HTTP/1.1 Host: http:/ /www. ejemplo.com Agente de usuario: Mozilla/5.0 (Macintosh; Intel Mac OS ;q=0.9,en-US;q=0.8,en;q=0.7 Conexión: keep-alive Fuente: http://foo.example.com Método de solicitud de control de acceso: PUT Sin embargo, en ausencia de una solicitud de verificación previa, aún se espera que un servidor permita una solicitud de origen cruzado, para esto el navegador solicita un encabezado Access-Control-Allow-Origin en la respuesta del servidor. Para resolver este problema, profundicé en la configuración del middleware .NET Core. El enfoque implicó habilitar CORS en el archivo Startup.cs de mi proyecto .NET. Definir una política CORS: Primero, definí una política en el método ConfigureServices. Esta política especifica los orígenes que pueden acceder a los recursos del servidor services.AddCors(options => { options.AddPolicy(“AllowSpecificOrigin”, builder => builder.WithOrigins(“http://example.com” ).AllowAnyMethod().AllowAnyHeader. ()); }); Aplicación de la política CORS: A continuación, en el método Configure, se habilitó la política CORS para todas las solicitudes entrantes agregando app.UseCors(“AllowSpecificOrigin”); antes de la aplicación.UseAuthorization();. Esta configuración permitió solicitudes de la fuente especificada mientras mantenía la aplicación segura.
