Cómo resolver el problema de Compartir recursos de origen cruzado al consumir un servicio ODATA en un sitio web con jQuery

Introducción

Después de todas las introducciones teóricas en los eventos recientes de SAP TechEd y algunos proyectos más pequeños en un sistema de sandbox local, finalmente estaba desarrollando mi propio primer servicio ODATA basado en Gateway que debería ser consumido por algún sitio web que ejecuta jQuery. Configurar nuestro pequeño servicio, crear algunas entidades, etc., no fue realmente algo especial después de todas las introducciones y el excelente material de aprendizaje en SCN.

Problemas del escenario del mundo real

Allá vamos, nuestros colegas de desarrollo de sitios web han incluido el URI del servicio proporcionado y están tratando de leer datos de nuestro servicio. Nada sucede dentro del script de jQuery en comparación con llamar directamente al servicio en un navegador donde obtenemos una respuesta agradable. ¿Qué pasó?

Al mirar las excelentes herramientas de desarrollo de Chrome, obtenemos un indicador de nuestro problema:

Continuamos nuestro viaje con herramientas de Google y finalmente terminamos obteniendo información realmente útil sobre 'Compartir recursos de origen cruzado'. Recomiendo echar un vistazo a lo siguiente:

• https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
• Resolviendo el problema de la "Política de mismo origen" de diferentes maneras por michaelherzog

Opciones

Al mirar la publicación del blog de michaelherzog Me hubiera encantado usar JSONP (como se describe en un manejador personalizado en esta publicación ). Desafortunadamente (según mi conocimiento) NetWeaver Gateway actualmente no admite JSONP y no quería renunciar al marco completo de Gateway y escribir un manejador desde cero como se describe en el blog mencionado de alessandro.spadoni .

Configurar un proxy en el servidor que proporciona el sitio web habría sido una opción, aunque quería evitar esto por dos razones: carga adicional en el servidor y poder resolver este problema por mi cuenta dentro de Gateway.

Entonces, la siguiente opción sería enviar un encabezado apropiado 'Access-Control-Allow-Origin' en la respuesta. No pude encontrar documentación específica de Gateway sobre personalización, por lo que parecía que necesitábamos ocuparnos de esto por nuestra cuenta.

Agregar el encabezado http

La primera y más atractiva opción, por supuesto, sería agregar el encabezado directamente en nuestra extensión de servicio. Y la buena noticia es que uno realmente puede hacer esto. Justo dentro de su clase 'DPC_EXT' tiene acceso al método /IWBEP/IF_MGW_CONV_SRV_RUNTIME~SET_HEADER que se puede usar para establecer campos de encabezado adicionales. ¡Bien, y nuestra primera solución ya está funcionando!

Ampliando la solución

Ahora que tenemos la primera solución en su lugar, quería ampliar esto un poco para no enviar '*' como el solicitante permitido y con esto permitir que cualquiera que pueda llamar a mi servidor ejecute este servicio dentro de su sitio web. En otras palabras, quería verificar el solicitante contra una pequeña tabla de clientes que permitiría a los consumidores potenciales de mi servicio. Sin embargo, no pude acceder al campo de encabezado http necesario 'Origen' de la solicitud para determinar el solicitante.

En lugar de usar el método de servicio de la entidad, decidí escribir un pequeño manejador http personalizado al que podría conectar en SICF y que verificaría el solicitante y, si está bien, agregaría el campo de encabezado. No entraré en detalles sobre cómo escribir la clase de manejador http en sí. Esto debería estar suficientemente documentado por aquí.

Sin embargo, al conectar el manejador adicional en SICF, me encontré con los siguientes problemas que quería compartir para hacer la vida un poco más fácil.

Orden de ejecución de clases de manejador y flujo de manejadores

En primer lugar, nuestra pequeña clase de manejador debe ejecutarse antes del manejador estándar /IWFND/CL_SODATA_HTTP_HANDLER. De lo contrario, nunca se alcanzará porque después de la ejecución del manejador estándar, el atributo if_http_extension~flow_rc se establecerá en 0 (