CORS: OPTIONS preflight call preceding a $http.post request and authentication header

[Pelle Krøgholt]

Hi,

I have some struggle to get authentication/token headers set on OPTIONS preflight calls before a POST with angular.js.

So my questions is:

1. should the service that I interact with allow all OPTIONS preflight calls? 

or 

2. do I simply implement the intercepter wrongly ? - based on interceptors (https://docs.angularjs.org/api/ng/service/$http) and http://www.html5rocks.com/en/tutorials/cors/ and  https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token i have this factory/config set up for my angular app:

  myApp.factory('authInterceptor', function ($rootScope, $q, $window) {

    return {

      request: function (config) {

        config.headers = config.headers || {};

        if ($window.sessionStorage.token) {

          config.headers.AuthToken = $window.sessionStorage.token;

        }        

        return config;

      },

      response: function (response) {

        if (response.status === 401) {

          // handle the case where the user is not authenticated

        }

        return response || $q.when(response);

      }

    };

  });

  myApp.config(function ($httpProvider) {

    $httpProvider.interceptors.push('authInterceptor');

    console.log($httpProvider.defaults.headers.common);

  });

this do not set a AuthToken on the OPTIONS preflight requests


hint/ suggests warmly welcomed!

//

pelle

[Pelle Krøgholt]

just an additional comment:

my use case is for a project that requires to run on multiple domains because it also involves a hybrid mobil application that will run on a mobile device - so server side I have this headers set:

"Access-Control-Allow-Origin", "*"

"Access-Control-Allow-Methods", "POST,GET,OPTIONS"

"Access-Control-Allow-Headers", "Content-Type, AuthToken"

[Jeff Hubbard]

You need to handle the OPTIONS preflight request on your server, and it needs to return the correct Access-Control-Allow-* headers for the incoming request.

[john.tiger]

I call blame on Angular for this mess.  Yes, I understand CORS is set on the server but far too many people are having trouble with the pre-flight handling on Angular.   For us, code that worked on Backbone did not work on Angular - there seems to be something in the way Angular works that creates problems with the pre-flight handling.  

To make it easier, Angular should have a core service that properly handles the pre-flight with the server side.  Either the core team chooses to ignore this issue or maybe Angular works better with Dart on the server side. 

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

[Pete Bacon Darwin]

Hi John

Could you put together a concrete list of things that Angular should do to support CORS better? What is the difference between CORS with Angular and CORS with Backbone? In your particular situation, what is the error you get when moving to Angular from Backbone?

Cheers

Pete

[TigerNassau]

Sure, we are application oriented so might need some help on how to track rec res msgs
- solution to make this whole cors thing painless is to have docs on how to set up client and server and probably a service/ factory to handle preflight handling. Give us a day or so and we will post a writeup on what headers we have been using so far on both client and server
Sent from my LG Mobile