Los navegadores por defecto implementan la securidad CORS.

Failed to load https://handysafariservicesint.azurewebsites.net/api/app/v1/DataService.svc/player/register: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. Origin ‘http://handysafari.local’ is therefore not allowed access. The response had HTTP status code 401.

JS por defecto manda OPTOINS/El navegador manda por defecto options

en el servicio tenemos que decirle ante una peticion OPTIONS

Y EN LA RESPUESTA TENEMOS QUE DECIRLE QUE METODOS PERMITE, qué headers pemite, y qué origen:

Access-Control-Allow-Headers: Content-Type, Authentication, Accept
Access-Control-Allow-Methods: POST,GET,PUT,DELETE
Access-Control-Allow-Origin: *

una vez el navegador detecte que se admiten, él, por si solo mandará la 2º petición correcta:

// Access-Control-Allow-Origin tienq ue estar en todos los headers, tanto en el de options genérico como en el de PUT/ÎOST etc… original

Ya con el método, headers, y body especificados:

PUT /api/app/v1/DataService.svc/player/register HTTP/1.1
Host: handysafariservicesint.azurewebsites.net
Connection: keep-alive
Content-Length: 63
Pragma: no-cache
Cache-Control: no-cache
Origin: http://handysafari.local
Authentication: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1MjQwNjI3NDEuNzF9.fFO19kZWOwegGVcGqcyTHWHOeC3BECW0ghcbeyzSEH4
User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; Pixel 2 XL Build/OPD1.170816.004) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Mobile Safari/537.36
Content-Type: application/json
Accept: */*
Referer: http://handysafari.local/route_summary_screen.html
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,es;q=0.8,de;q=0.7

Documentation
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Problem
This problems occurs when from a website a call is made to another domain and request have custom headers. For security reasons, the web browsers stops the execution of this call. To allow this call to be made, a configuration must be done in the server when the call is is made.

What the web browser does is, first it makes a call to the URL, without headers and without body, with the method «OPTIONS». The server then must return a 200 OK with headers that tells the browser from which domains the call is allowed, with which method and with which headers.

If the headers returned are correct, the web browser makes a second call, which will be the correct call.

Example
We want, from http://testserver1.com, with javascript, make a call to http://testserver2.com. The web browser will reject the call to be made with a cross domain error.

To solve it, the server «testserver2.com», must accept a request in the same URL with the method «OPTIONS», returning this headers:

Access-Control-Allow-Origin: http://testserver1.com
Access-Control-Allow-Methods: POST,GET,PUT,DELETE
Access-Control-Allow-Headers: Content-Type, Authentication, Accept

Access-Control-Allow-Origin: Allowed domains. We can put the wildcard ‘*’ to allow any domain, but it is not recommended
Access-Control-Allow-Methods: The methods the server will accept. In the example we have put the 4 methods we are used to use
Access-Control-Allow-Headers:The headers the server will accept

The web browser will validate the headers after doing the first call with the «OPTIONS» method, and if all is correct, it will make a second call, which will be the correct one. But this has a problem, and is that, in the javascript code, the returned data in the function is the data of the first call, it means, the «OPTIONS» call, so the javascript can not read the response from the second and correct call. We are still researching how to solve this.

https://developer.mozilla.org/es/docs/Web/HTTP/Access_control_CORS