Esta no es una respuesta directa, sino una dirección de diseño ligeramente diferente:
No publique los datos como un formulario, sino como un objeto JSON que se asignará directamente al objeto del lado del servidor, o use la variable de ruta de estilo REST
Ahora sé que ninguna de las opciones podría ser adecuada en su caso, ya que está tratando de pasar una clave XSRF. Mapearlo en una variable de ruta como esta es un diseño terrible:
http://www.someexample.com/xsrf/{xsrfKey}
Porque, por naturaleza, también querría pasar la clave xsrf a otra ruta /login
,/book-appointment
etc. y no querrás desordenar tu bonita URL
Curiosamente, agregarlo como un campo de objeto tampoco es apropiado, porque ahora en cada objeto json que pasa al servidor, debe agregar el campo
{
appointmentId : 23,
name : 'Joe Citizen',
xsrf : '...'
}
Ciertamente no desea agregar otro campo en su clase del lado del servidor que no tenga una asociación semántica directa con el objeto de dominio.
En mi opinión, la mejor manera de pasar su clave xsrf es a través de un encabezado HTTP. Muchas bibliotecas de marco web del lado del servidor de protección xsrf lo admiten. Por ejemplo, en Java Spring, puede pasarlo usando el X-CSRF-TOKEN
encabezado .
La excelente capacidad de Angular de vincular objetos JS a objetos UI significa que podemos deshacernos de la práctica de publicar formularios todos juntos y publicar JSON en su lugar. JSON se puede deserializar fácilmente en objetos del lado del servidor y admitir estructuras de datos complejas como mapas, matrices, objetos anidados, etc.
¿Cómo publicar matriz en una carga útil de formulario? Tal vez así:
shopLocation=downtown&daysOpen=Monday&daysOpen=Tuesday&daysOpen=Wednesday
o esto:
shopLocation=downtwon&daysOpen=Monday,Tuesday,Wednesday
Ambos tienen un diseño pobre.