I have an AngularJS web app that accesses a .NET WebAPI server end. Authentication is implemented through the AngularJS-OAuth2 library. I have the app and the WebAPI hosted in localhost under two different port numbers. I have also enabled Microsoft.Owin.Cors package on the server end to handle cross-domain requests.
In Chrome, GET and POST requests return data to the front-end. By inspecting the traffic through Fiddler I could see that a pair of requests/responses are sent (preflight/OPTIONS + actual) and also the relevant CORS headers (including origin and Access-Control-* headers) in both the requests and the responses. All as expected.
However, in Internet Explorer, my GET requests return data through the $http service but the POST does not. I could inspect that there are no preflight requests or CORS headers (I think IE treats different ports as the same origin). In checking the POST request/response in IE through Fiddler I could observe that it returns HTTP status 200 but state of Aborted (with X-ABORTED-WHEN: SendingResponse flag set). I could also inspect the JSON response with the correct data returned.
I have also tried setting a high timeout to no avail. The $http call looks like this:
return $http.post(apiUrl + "/search", service.getParameters(), { timeout: 600000 })
.success(function (data) {...
Fiddler shows something like this for the IE POST request:
Also (only) in IE, an unintentional page refresh is also triggered with the same button click as this POST operation.
Why does Internet Explorer abort only the POST requests when the correct data is also returned to the client and when Chrome does not have any issues at all?
Additional Information
Request:
POST https://localhost:44321/api//search HTTP/1.1
Content-Type: application/json;charset=utf-8
Accept: application/json, text/plain, */*
Authorization: Bearer <token>
Referer: https://localhost:44322/search
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:44321
Content-Length: 202
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: .ASPXANONYMOUS=<cookie>
Reponse:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: <file>
X-Powered-By: ASP.NET
Date: Wed, 10 Feb 2016 13:43:45 GMT
Content-Length: 2284
Fiddler session properties:
SESSION STATE: Aborted.
Request Entity Size: 202 bytes.
Response Entity Size: 2284 bytes.
== FLAGS ==================
BitFlags: [IsHTTPS, ClientPipeReused, ServerPipeReused] 0x19
X-ABORTED-WHEN: SendingResponse
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 41889
X-EGRESSPORT: 41890
X-HOSTIP: ::1
X-PROCESSINFO: avp:3584
X-RESPONSEBODYTRANSFERLENGTH: 2,284
X-SERVERSOCKET: REUSE ServerPipe#168
== TIMING INFO ============
ClientConnected: 19:13:42.408
ClientBeginRequest: 19:13:42.444
GotRequestHeaders: 19:13:42.444
ClientDoneRequest: 19:13:42.772
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 19:13:42.413
FiddlerBeginRequest: 19:13:42.772
ServerGotRequest: 19:13:42.772
ServerBeginResponse: 19:13:45.360
GotResponseHeaders: 19:13:45.360
ServerDoneResponse: 19:13:45.360
ClientBeginResponse: 19:13:45.360
ClientDoneResponse: 19:13:45.360
Overall Elapsed: 0:00:02.915
The response was buffered before delivery to the client.
== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state at the time of the request.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.
I believe you get bitten by the P3P policy requirement of IE here:
Internet Explorer supports a cookie-restricting privacy feature called P3P. Web developers often get tripped up by it because no other browser implements the P3P standard.
It seems similar to those QAs:
CORS request with IE11
CORS doesn't work with cookies in IE10
Internet Explorer 10 is ignoring XMLHttpRequest 'xhr.withCredentials = true'
Here's a blog post with an example how to send P3P information. Here's a document from Microsoft about P3P configuration
Related
I have recently started using libCurl for client-server communication project where I use libcurl in the client side. We used to use WinHTTP, but did not find a way to add TLS 1.3 backward compatibility with earlier windows versions.
The cnonce is part of Digest Authentication headers.
When my project was earier using WinHTTP, the cnonce used to be hexadecimal.
Eg:
cnonce="a01e21c2a827ec6d3d9b6e1745ca8a0b"
HTTP Header
Server to client:
HTTP/1.1 401 Unauthorized
Content-Length: 26
WWW-Authenticate: Negotiate
WWW-Authenticate: Digest realm="a2ffc77914d6e791d", qop="auth",nonce="3f3da4b94e249058", opaque ="3b3542c"
Client to Server:
POST /wsman HTTP/1.1
Connection: Keep-Alive
Content-Type: application/soap+xml;charset=UTF-8
User-Agent: Openwsman
Content-Length: 889
Host: 10.138.141.178:623
Authorization: Digest username="PostMan",realm="a2ffc77914d6e791d",nonce="3f3da4b94e249058",uri="/wsman",cnonce="a01e21c2a827ec6d3d9b6e1745ca8a0b",nc=00000001,response="9dd37ef997ef332e46dff0f868b3de89",qop="auth",opaque="3b3542c"
When I look at the HTTP header I find that the cnonce is alphanumeric with Curl.
Eg:
cnonce="NDlmYTM0ZjVlM2IzNTNhMDNiNDk0MzQ1MzdlYmFlMzA="
HTTP Header
Server to Client
HTTP/1.1 401 Unauthorized
Content-Length: 0
Connection: Keep-Alive
Content-Type: application/soap+xml;charset=UTF-8
WWW-Authenticate: Digest realm="a2ffc77914d6e791d", nonce="5bf1156647e8eb42", algorithm="MD5", qop="auth", opaque="661d9eae", userhash=true
Client to Server
POST /wsman HTTP/1.1
Host: blr-5cg64728l6.amd.com:623
Authorization: Digest username="PostMan", realm="a2ffc77914d6e791d", nonce="5bf1156647e8eb42", uri="/wsman", cnonce="NDlmYTM0ZjVlM2IzNTNhMDNiNDk0MzQ1MzdlYmFlMzA=", nc=00000001, qop=auth, response="6847e465c9c90b40264b736070f721da", opaque="661d9eae", algorithm=MD5, userhash=true
Accept: */*
Content-Type: application/soap+xml;charset=UTF-8
User-Agent: Openwsman
Content-Length: 897
With alpha numeric cnonce the server is not responding back consistantly. Is there a way to specify in libcurl to generate hexadecimal cnonce - explicitly?
Note: To avoid security risk, the fields have been modified in the headers above.
I am using LibCurl: 7.73
with OpenSSL TLS backend: 1.1.1h
What would cause Internet Explorer to replace the HTTP header
Authorization : Bearer <server-provided-token>
with
Authorization : Negotiate <some token>
when making an AJAX request?
Details
In Internet Explorer, some AJAX requests that are configured to contain the header Authorization: Bearer ... are being sent by Internet Explorer with the header Authorization: Negotiate ... instead.
For example, Fiddler shows that the first two of three requests contain the Authorization : Bearer... header, while the third suddenly contains the Authorization : Negotiate... header. The first two requests are successful, and the third fails because the request can't be properly authenticated.
All of the requests are constructed using the same client-side code, and are made one after another (within the span of a second). I have verified that the Authorization header correctly contains the Bearer token in all three cases up until the point the request is provided to the browser.
Also, I'm not seeing the same behavior in Chrome; it's only occurring in IE.
Request 1
GET http://localhost/myapp/api/User HTTP/1.1
Accept: application/json, text/plain, */*
Authorization: Bearer oEXS5IBu9huepzW6jfh-POMA18AUA8yWZsPfBPZuFf_JJxq-DKIt0JDyPXSiGpmV_cpT8FlL3D1DN-Tv5ZbT73MTuBOd5y75-bsx9fZvOeJgg04JcO0cUajdCH2h5QlMP8TNwgTpHg-TR9FxyPk3Kw6bQ6tQCOkOwIG_FmEJpP89yrOsoYJoCfrAoZ7M4PVcik9F9qtPgXmWwXB2eHDtkls44wITF_yM_rPm5C47OPCvMVTPz30KwoEPi6fHUcL3qHauP-v9uypv2e48TyPHUwLYmNFxyafMhBx4TkovnRcsdLHZiHmSjMq0V9a2Vw70
Referer: http://localhost/client/login.html
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost
DNT: 1
Connection: Keep-Alive
Request 2
POST http://localhost/myapp/api/Permissions HTTP/1.1
Referer: http://localhost/client/#/Dashboard
Content-Type: application/json
Authorization: Bearer oEXS5IBu9huepzW6jfh-POMA18AUA8yWZsPfBPZuFf_JJxq-DKIt0JDyPXSiGpmV_cpT8FlL3D1DN-Tv5ZbT73MTuBOd5y75-bsx9fZvOeJgg04JcO0cUajdCH2h5QlMP8TNwgTpHg-TR9FxyPk3Kw6bQ6tQCOkOwIG_FmEJpP89yrOsoYJoCfrAoZ7M4PVcik9F9qtPgXmWwXB2eHDtkls44wITF_yM_rPm5C47OPCvMVTPz30KwoEPi6fHUcL3qHauP-v9uypv2e48TyPHUwLYmNFxyafMhBx4TkovnRcsdLHZiHmSjMq0V9a2Vw70
Accept: application/json, text/plain, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost
Content-Length: 1419
DNT: 1
Connection: Keep-Alive
Pragma: no-cache
<Post Data Removed>
Request 3
GET http://localhost/myapp/api/UserPreferences/Dashboard HTTP/1.1
Referer: http://localhost/client/#/Dashboard
Content-Type: application/json
Authorization: Negotiate YHsGBisGAQUFAqBxMG+gMDAuBgorBgEEAYI3AgIKBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHqI7BDlOVExNU1NQAAEAAACXsgjiBgAGADMAAAALAAsAKAAAAAYBsR0AAAAPVk1ERVZFTlYtU1JTQ0VSSVM=
Accept: application/json, text/plain, */*
Accept-Language: en-US
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Connection: Keep-Alive
DNT: 1
Host: localhost
The requests are being made via the AngularJS $http service, and the back-end is ASP.NET Web API hosted in IIS.
We had a problem where Internet Explorer was caching credentials. We could fix the problem by using the following script:
document.execCommand('ClearAuthenticationCache', 'false');
see: Wikipedia
I've just come across this issue too.
What was odd is that it worked fine on my development machine, it was when I deployed it the issue arose.
Again it worked fine in Chrome, Firefox etc.
It turns out that the issue is that IE was detecting the site was on the localintranet zone and was therefore trying to automatically trying log on (it was set by group policy - this is an internal app).
My workaround was that (luckily) it was only autodetecting local intranet zone when using a server name that wasn't an FQDN (e.g. myserver) - but using the full A
I had the same problem in a knockoutjs application, it worked fine in Chrome and Firefox but not in IE.
I also used Fiddler and noticed that the first ajax call used Bearer as intended and returned successfully. But then IE started to loop and send the subsequent ajax calls over and over again with the Negotiate authorization instead!
In my case it was some sort of timing issue in IE, I solved it by making the ajax calls that loaded data during rendering synchronous.
me.loadLimits = function () {
$.ajax({
type: 'GET',
dataType: 'json',
contentType: 'application/json',
url: '/api/workrate/limits',
headers: me.headers,
async: false,
success: function (result) {
...
I also encountered this issue when I was kicking off multiple data loads in my angular app.
I worked around this by detecting the browser and if IE, delayed each request by 50ms based on the index of the call:
return $q(function(resolve, reject) {
var delay = self.widget.useDelayLoading ? self.widget.index * 50 : 0;
setTimeout(function() {
restService.genericApi(self.widget.url, false).queryPost(json).$promise
.then(
function(r) { resolve(r); },
function(e) { reject(e); }
);
}, delay);
});
Interestingly, when I used $timeout, I had to increase the delay to 100ms.
We had faced similar issue with angular and web api. Issue happens when the system tries to access some resource at root level which had Windows Authentication enabled. In our case, application was trying to get the favicon from IIS root. Once this request gets unauthorized, IE will try getting the resouce with negotiation header; though it fails again. But from this point onwards, IE keep sending negotiate header instead of our bearer token. This is due to the settings in IE, which I think is in Internet Options -> Advanced tab -> Enable Integrated Windows Authentication in the Security section (not sure, I forgot the exact stuff).
Fix was either give anonymous access to root level or to the resource location which app is trying to access (bad option) or have document.execCommand('ClearAuthenticationCache', false); in the app.js file.
In my case, IE alternated between sending a bad request, followed by a good request on a second attempt, then followed by a bad request again and so on.
After trying several approaches to causing IE to retry - it appears that returning a 307 (Temporary redirect) with the same request url in the Location header solves the issue.
e.g. for a request to "http://myUrl/api/service/"
HTTP 307 Temporary Redirect
Location: http://myUrl/api/service/
IE retries the call with the proper data.
Edit: This method might be dangerous as it might create an infinite loop. A possible solution to work around it, is to return some counter as part of the url in the Location header and analyze it when receiving the call again.
I built a oData-Service which works well.
Now I want to query them with Breeze but I always get an 404 error.
In Fiddler I see first a 200 with empty Body and then follows the 404 with "No HTTP resource was found that matches the request URI".
But running in a normal browser the odata Service delivers the right data.
I debug it and set a breakpoint on the Server to see if the service is called correctly. After sending the request the breakpoint shows that the Service is called. But parallel to the break breeze calls the fail-method of
manager.executeQuery(query)
.then(querySucceeded)
.fail(queryFailed);
and e.message is empty.
Any idea??? :-/
Next entry...
I deactivate CORS and now I get the 404 immediately.
Here is the request:
OPTIONS xxx:8080/myDataService/odata/Person?$select=Name HTTP/1.1
Host: xxx:8080
Connection: keep-alive
Access-Control-Request-Method: GET
Origin:localhost:61244
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.99 Safari/537.36
Access-Control-Request-Headers: dataserviceversion, accept
Accept: /
Referer: http://localhost:61244/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
and here the answer:
HTTP/1.1 404 Not Found
Content-Length: 178
Content-Type: application/json; odata.metadata=minimal
Server: Microsoft-HTTPAPI/2.0
OData-Version: 4.0
Date: Mon, 19 Jan 2015 12:11:48 GMT
{
"error":{
"code":"","message":"No HTTP resource was found that matches the request URI xxx:8080/myDataService/odata/Person?$select=Name'."
}
}
No surprise that the OPTION request passes; you've probably got the server set to say "OK" to every request ... and that's just fine for now.
The rejection has to do with the address of your GET request: xxx:8080/myDataService/odata/Person. Are you sure that's the right endpoint? The path is usually plural (Persons).
It's easy enough to just paste that url into a browser address bar and see what it does.
It might be just angularjs issue! I am very new to the frontend and angularjs.
I have an angularjs sign in service which calls the url '/signin/facebook/' to sign in, it seems the backend is redirected correctly and calling the facebook oauth but I got the follow error.
[Angularjs sign in service]
app.factory('fbSigninService', function($http){
return{
fb_signin:function(scope){
var $promise=$http.post('/signin/facebook/',JSON.stringify(scope));
}
}
});
[error]
XMLHttpRequest cannot load https://www.facebook.com/v1.0/dialog/oauth?client_id=xxxxxxxxxxxxxxx&respon…t%3A8080%2Fsignin%2Ffacebook%2F&state=12431991-7555-4ed4-90b9-728e11c721f0. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:8080' is therefore not allowed access.
so when I click on the link directly from the browser's console from the error, it authenticated fine!
https://www.facebook.com/v1.0/dialog/oauth?client_id=xxxxxxxxxxxxxxx&respon…t%3A8080%2Fsignin%2Ffacebook%2F&state=12431991-7555-4ed4-90b9-728e11c721f0
Update #01
I don't think, javascript suppose to call the facebook auth, the javascript should call the same host '/signin/facebook/' and then the backend should make the facebook auth call???
Update #02 15/Oct/2014
1) I have updated the code to allow cross origin but still getting the same error.
2) when I re-read the error again, it actually saying "facebook"'s doesnt' have 'Access-Control-Allow-Origin' header is present on the requested resource.
So the question is, how am I supposed to call from angularjs -> java api -> redirect to facebook login page?
[Java]
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "x-requested-with");
[Headers]
Request URL:http://localhost:8080/index.html
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:JSESSIONID=3BA4D9DBF38686F2AA527BF408D28EC1
Host:localhost:8080
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/31.0.1650.63 Chrome/31.0.1650.63 Safari/537.36
Response Headersview source
Access-Control-Allow-Headers:x-requested-with
Access-Control-Allow-Methods:POST, GET, OPTIONS, DELETE
Access-Control-Allow-Origin:*
Access-Control-Max-Age:3600
Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Content-Length:1839
Content-Type:text/html
Date:Wed, 15 Oct 2014 23:15:01 GMT
Expires:0
Last-Modified:Wed, 08 Oct 2014 22:10:40 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
X-Application-Context:application
X-Content-Type-Options:nosniff
X-Frame-Options:DENY
X-XSS-Protection:1; mode=block
Update #03
I am using the Advance REST client to call the '/signin/facebook/', it seems working fine.
Redirect #1
To:https://www.facebook.com/v1.0/dialog/oauth?client_id=273118692865062&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fconnect%2Ffacebook&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2 with status: 302 Show explanation HTTP/1.1 302 Found
Redirection information has not been cached.
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: x-requested-with
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
X-Application-Context: application
Location: https://www.facebook.com/v1.0/dialog/oauth?client_id=273118692865062&response_type=code&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fconnect%2Ffacebook&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2
Content-Language: en-US
Content-Length: 0
Date: Thu, 16 Oct 2014 21:50:21 GMT
Redirect #2
To:http://localhost:8080/connect/facebook?code=AQCq9wnl_LeecAuWkR0D2252YZICiuWiaFeSUqISaUzQ7vfHHWI1sMsqSWO5kpgUQG0URi5NI52UX3zBpKTwj7rnnzQKOnxjUbyxwN-Z3a3rt1G3P84ONaCrsUO-LuM0_bpvROzWzno0pK9_lf-KI5JhqBvWWRGuWGEKz1FKl816rbrEP_nmh97BBM5oW3IYbvjuhKSghINp2ilADgLabMFTC76zN41HRjWE7X1bXGLaXY3EtQG61R5FGo7QV-W9iWtH3PCZw4gP_DByiDdUrObo1OsECWSkdh6q7a-EsuJ_QZe5zqQJbhEf2GHal5AC9YU&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2#_=_ with status: 302 Show explanation HTTP/1.1 302 forced.302
Redirection information has not been cached.
status: 302 forced.302
version: HTTP/1.1
cache-control: private, no-cache, no-store, must-revalidate
content-length: 0
content-security-policy: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net *.atlassolutions.com chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net wss://*.facebook.com:* ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:* *.atlassolutions.com http://attachment.fbsbx.com https://attachment.fbsbx.com;
content-type: text/html; charset=utf-8
date: Thu, 16 Oct 2014 21:50:21 GMT
expires: Sat, 01 Jan 2000 00:00:00 GMT
facebook-api-version: v1.0
location: http://localhost:8080/connect/facebook?code=AQCq9wnl_LeecAuWkR0D2252YZICiuWiaFeSUqISaUzQ7vfHHWI1sMsqSWO5kpgUQG0URi5NI52UX3zBpKTwj7rnnzQKOnxjUbyxwN-Z3a3rt1G3P84ONaCrsUO-LuM0_bpvROzWzno0pK9_lf-KI5JhqBvWWRGuWGEKz1FKl816rbrEP_nmh97BBM5oW3IYbvjuhKSghINp2ilADgLabMFTC76zN41HRjWE7X1bXGLaXY3EtQG61R5FGo7QV-W9iWtH3PCZw4gP_DByiDdUrObo1OsECWSkdh6q7a-EsuJ_QZe5zqQJbhEf2GHal5AC9YU&state=00d8c7ee-e178-4d2b-bc86-500505d5eac2#_=_
pragma: no-cache
strict-transport-security: max-age=15552000; preload
x-content-type-options: nosniff
x-fb-debug: ESLliRqmaFv9DBXraKZN4X3FRH36D8lnMegz7e9Udqv5aECkJwU7DiWbQ+g+d9X4G+30cP27b3nCs9BsDIlM6w==
x-frame-options: DENY
x-xss-protection: 0
Redirect #3
To:http://localhost:8080/connect/facebook#_=_ with status: 302 Show explanation HTTP/1.1 302 Found
Redirection information has not been cached.
Server: Apache-Coyote/1.1
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: x-requested-with
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
X-Application-Context: application
Location: http://localhost:8080/connect/facebook
Content-Language: en-US
Content-Length: 0
Date: Thu, 16 Oct 2014 21:50:21 GMT
Though am late but I think it can help to an extent.
Spring-social APIs handle all this out of the box. I have created a sample app which uses Spring-social and AngularJS. Its a very basic flow but may help.
spring-social-angularjs-sample
You need to allow requests to outside of your domain (this is a security mechanism enforced by your browser which blocks by default requests to foreign domain addresses - read).
you probably need to configure a rule to allow your client to access Facebook - needs to be added in your server's configuration (not in angular)
how to fix? - django, node, apache, iis, ...
The issue is with cross-origin requests, not the authentication itself. There is no specific configuration in spring social or security modules to handle facebook or any other provider. Answering one of your doubts - yes, the backend should handle all of the dance, you do not have to do anything from your front-end apart from calling the authentication address.
At first, try to authenticate through your server against facebook API by doing the same call as you do from your angular client but using Advanced REST client for Chrome. See the outcome.
Then, I would start with proper implementation of CORS filters in your case. To test that CORS is working at least to some extent, create a controller to handle a POST request and send one from Angular. Test it first without using the Facebook API. If you cannot send a POST, this means you have to change your CORS filters before you proceed with using facebook API for authentication.
If your simple POST works (or, moreover, if it doesn't) please refer to Tomcat documentation for the catalina implementation of Cors Filter http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter . They provide sample configuration of filters which should allow you to get rid of any cors issues (you can add one more header to the cors allowed headers, "Authorization").
If none of these above help you, let me know.
I have a weird problem. I am testing this using Angular.js 1.2.15.
I want to send a POST request to a RESTful API backend on another domain (and I want to use $http directly, not $resource).
var mapData = {
'some': 'keys',
'other': 'keys'
}
$http.post(endPoint, mapData);
This is what happens: An OPTIONS request is sent first, with the following request headers:
OPTIONS /api/maps HTTP/1.1
Host: myhost.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://0.0.0.0:9000
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/36.0.1985.125 Chrome/36.0.1985.125 Safari/537.36
Access-Control-Request-Headers: accept, content-type
Accept: */*
Referer: http://0.0.0.0:9000/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
The response clearly shows that requests from other origins and with every method are allowed:
HTTP/1.1 204 No content
Server: Varnish
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: *
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Access-Control-Max-Age: 0
Content-Type: text/plain charset=UTF-8
Accept-Ranges: bytes
Date: Tue, 02 Sep 2014 14:50:16 GMT
X-Varnish: 166874803
Age: 0
Via: 1.1 varnish
Connection: close
Cache-Control: max-age=0, private
X-Varnish-Cache: MISS
But then, the POST request is not even sent by the browser (Chromium 36), i.e. it does not show a POST request in the network tab of the dev console.
Instead, the following is shown in the console:
XMLHttpRequest cannot load http://myhost.com/api/maps. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://0.0.0.0:9000' is therefore not allowed access.
Now, what is totally weird: GET requests to the same API work, and are not preceded by an OPTIONS request (or maybe it is not shown in the network tab).
HTTP/1.1 304 Not Modified
Server: nginx/1.4.7
Content-Type: application/json; charset=utf-8
Status: 200 OK
X-UA-Compatible: IE=Edge,chrome=1
ETag: "baca3b7547fed3377088eb81fe083ff8"
X-Request-Id: b2552dc4fdef2541c841e3d5e12d337e
X-Runtime: 0.110003
X-Rack-Cache: miss
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Headers: DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type
Accept-Ranges: bytes
Date: Tue, 02 Sep 2014 14:54:31 GMT
X-Varnish: 166874831 166874142
Age: 6223
Via: 1.1 varnish
Connection: keep-alive
Cache-Control: max-age=0, private
X-Varnish-Cache: HIT
I really have no clue what the problem could be here. Is it Angular's implementation? Or is it a misconfiguration on the server? The guys responsible for the API told me it usually works with all their web apps.
I understand that this is a CORS problem and I am by no means an expert when it comes to that, but hey, Access-Control-Allow-Origin: * should do the trick, shouldn't it?
UPDATE: It works when using plain XMLHttpRequest:
var http = new XMLHttpRequest();
var url = endPoint;
var params = JSON.stringify(mapData);
http.open("POST", url, true);
I get a 200 back.
What is the matter here?
Nginx has to be compiled with http://nginx.org/en/docs/http/ngx_http_headers_module.html for Access-Control-Allow-Origin: * to work. Do you have this module installed?
location / {
add_header Access-Control-Allow-Origin *;
}