Cross-Origin Request Blocked with CORS headers present - angularjs

on the server side I have the following filter in apache which allow all methods and all origins by defaults
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CorsFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Using angular $http One post is working, but another fail failed. The request that fails talks to another app on the same apache.
Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at http://localhost:..
(Reason: CORS header 'Access-Control-Allow-Origin'
does not match 'http://localhost:8100, http://localhost:8100').
But the response header does contain the ACAO
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
access-control-allow-credentials: true, true
access-control-allow-origin: http://localhost:8100, http://localhost:8100
Vary: Origin
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 22 Oct 2015 04:35:29 GMT
Where did the ' http://localhost:8100, http://localhost:8100' come from ? Do you think it is angular $http or Apache problem ?

Access-Control-Allow-Origin accepts either '*' or a single origin for its value. You can't put a comma-separated list there.
The browser is matching the origin (http://localhost:8100 against http://localhost:8100, http://localhost:8100 and not getting a match.
You have a similar problem on the line before. It looks like you are running the code to insert your CORS headers twice.

Related

react app cors error in backend connection

I have troubles with CORS error.
I am developing a react app with create-react-app.
I am using axios to fetch data from BE but when I try to fetch I got cors error in chrome:
I tried to disable CORS policy in chrome but nothing is working.
Is very strange because the login route works while the other routes that need a session in header are not working. I tried also to call them through command line CURL and they work as expected.
With the curl command line I dumped the response header and I got:
HTTP/1.1 200
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
Access-Control-Allow-Origin: *
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
Content-Type: application/json
Transfer-Encoding: chunked
Date: Tue, 12 Oct 2021 13:22:07 GMT
My frontend is in http://localhost:3000 while the backend is in another domain on internet.
What am I doing wrong?
You could either proxy the backend or request the backend to add CORS headers, like Access-Control-Allow-Origin, Access-Control-Allow-Methods,
Access-Control-Allow-Headers
Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
I solved the problem enabling (in BE part) the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Max-Age: 3600
Access-Control-Allow-Headers: *
Adding these, the preflight calls succeded and I was able to fetch the API

Refused to load the image because it violates the following Content Security Policy directive: "default-src 'none'"

Refused to load the image because it violates the following Content Security Policy directive: "default-src 'none'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.
The site gets loaded at first but after doing a refresh it gives the above error. I have built my site using React.js in front-end and back-end is of Node.js. My site is deployed on heroku.
Edit 1:
Also getting below this in issues
Content Security Policy of your site blocks some resources because their origin is not included in the content security policy header
The Content Security Policy (CSP) improves the security of your site by defining a list of trusted sources and instructs the browser to only execute or render resources from this list. Some resources on your site can't be accessed because their origin is not listed in the CSP.
To solve this, carefully check that all of the blocked resources listed below are trustworthy; if they are, include their sources in the content security policy of your site. You can set a policy as a HTTP header (recommended), or via an HTML tag.
⚠️ Never add a source you don't trust to your site's Content Security Policy. If you don't trust the source, consider hosting resources on your own site instead.
1 directive
Resource Status Directive Source code
https://xxxx.herokuapp.com/favicon.ico blocked img-src
Edit 2:
Response Header
HTTP/1.1 500 Internal Server Error
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-type, Accept, Authorization
Content-Security-Policy: default-src 'none'
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Content-Length: 148
Date: Sat, 09 Jan 2021 18:23:41 GMT
Via: 1.1 vegur
Edit 3:
For me, I forgot to declare
const path = require("path");
in my server.js and that was causing the above problem
You have status code 500 Internal Server Error Server, but not 200 OK. In this case NodeJS runs the finalhandler which publish the default CSP: Content-Security-Policy: default-src 'none' for security reasons.
default-src 'none' blocks all resourses include images.
I guess you have /favicon.ico blocked, browsers loads it by default from the web pages root /, here is a similar issue was solved.
You need to fix 500 Internal Server Error Server.

Angular + Node + Express + Passport + oauth2orize unique CORS issues

I've built an API to use for local auth and Facebook auth.
I'm using node, express, passport and oauth2orize for the authorization process.
I'm now running the API perfectly through terminal applications and API testing suites, however, when making calls to my authentication endpoints from angular I receive the following:
Local auth:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
http://localhost:4200/oauth2/auth
?client_id=[CLIENT_ID]
&redirect_uri=http:%2F%2Flocalhost:4200%2Foauth2%2Fauth%2Fcallback (http://localhost:4200/oauth2/auth/callback)
&response_type=code.
This can be fixed by moving the resource to the same domain or enabling CORS.
Facebook auth:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
https://www.facebook.com/dialog/oauth
?response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2Fauth%2Ffacebook%2Fcallback (http://localhost/auth/facebook/callback)
&client_id=[CLIENT_ID].
This can be fixed by moving the resource to the same domain or enabling CORS.
I have had CORS issues in the past and integrated the npm 'cors' middleware module found at https://www.npmjs.com/package/cors
CORS init:
var cors = require('cors');
api.use(cors());
With my previous issues, this was sufficient, however, with these new CORS issues it's not helping.
I've also noticed, in Firefox, if I click on the error message, a new dialog window opens up as it should and the server continues to correctly authorize the user.
Could anyone help?
UPDATE 1:
Check comments for screenshot of debug info.
UPDATE 2:
Response headers for the last 2 requests performed in the login flow.
204:
Access-Control-Allow-Credentials: true
Connection: keep-alive
Date: Fri, 06 Feb 2015 15:26:43 GMT
Vary: Origin
X-Powered-By: Express
access-control-allow-headers: authorization
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-origin: http://localhost:8100
302:
Access-Control-Allow-Credentials: true
Connection: keep-alive
Content-Length: 138
Content-Type: text/plain; charset=utf-8
Date: Fri, 06 Feb 2015 15:26:43 GMT
Location: http://localhost:4200/oauth2/auth/callback?code=[CODE_HERE]
Set-Cookie: connect.sid=[SID_HERE]; Path=/; HttpOnly
Vary: Origin, Accept
X-Powered-By: Express
access-control-allow-origin: http://localhost:8100
The earlier examples in the docs don't include handling the preflight request, and do not specify any origins, which is required if you want to send any credentials with the requests (for example, your authorization header). Here's an example:
var whitelist = ['https://localhost:4200']; // Acceptable domain names. ie: https://www.example.com
var corsOptions = {
credentials: true,
origin: function(origin, callback){
var originIsWhitelisted = whitelist.indexOf(origin) !== -1;
callback(null, originIsWhitelisted);
// callback(null, true); uncomment this and comment the above to allow all
}
};
// Enable CORS
app.use(cors(corsOptions));
// Enable CORS Pre-Flight
app.options('*', cors(corsOptions));

spring social facebook + api + angularjs (How to call from angular -> spring api -> redirect to facebook login)

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.

Confused about how to handle CORS OPTIONS preflight requests

I'm new to working with Cross Origin Resource Sharing and trying to get my webapp to respond to CORS requests. My webapp is a Spring 3.2 app running on Tomcat 7.0.42.
In my webapp's web.xml, I have enabled the Tomcat CORS filter:
<!-- Enable CORS (cross origin resource sharing) -->
<!-- http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter -->
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CorsFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
My client (written with AngularJS 1.2.12) is trying to access a REST endpoint with Basic Authentication enabled. When it makes it's GET request, Chrome is first preflighting the request, but is receiving a 403 Forbidden response from the server:
Request URL:http://dev.mydomain.com/joeV2/users/listUsers
Request Method:OPTIONS
Status Code:403 Forbidden
Request Headers:
OPTIONS /joeV2/users/listUsers HTTP/1.1
Host: dev.mydomain.com
Connection: keep-alive
Cache-Control: max-age=0
Access-Control-Request-Method: GET
Origin: http://localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Access-Control-Request-Headers: accept, authorization
Accept: */*
Referer: http://localhost:8000/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Response Headers:
HTTP/1.1 403 Forbidden
Date: Sat, 15 Feb 2014 02:16:05 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 0
Connection: close
I'm not entirely sure how to proceed. The Tomcat filter, by default, accepts the OPTIONS header to access the resource.
The problem, I believe, is that my resource (the request URL) http://dev.mydomain.com/joeV2/users/listUsers is configured to only accept GET methods:
#RequestMapping( method=RequestMethod.GET, value="listUsers", produces=MediaType.APPLICATION_JSON_VALUE)
#ResponseBody
public List<User> list(){
return userService.findAllUsers();
}
Does this mean that I must make that method/endpoint accept OPTIONS method as well? If so, does that mean I have to explicitly make every REST endpoint accept the OPTIONS method? Apart from cluttering code, I'm confused how that would even work. From what I understand the OPTIONS preflight is for the browser to validate that the browser should have access to the specified resource. Which I understand to mean that my controller method should not even be called during the preflight. So specifying OPTIONS as an accepted method would be counter-productive.
Should Tomcat be responding to the OPTIONS request directly without even accessing my code? If so, is there something missing in my configuration?
I sat down and debugged through the org.apache.catalina.filters.CorsFilter to figure out why the request was being forbidden. Hopefully this can help someone out in the future.
According to the W3 CORS Spec Section 6.2 Preflight Requests, the preflight must reject the request if any header submitted does not match the allowed headers.
The default configuration for the CorsFilter cors.allowed.headers (as is yours) does not include the Authorization header that is submitted with the request.
I updated the cors.allowed.headers filter setting to accept the authorization header and the preflight request is now successful.
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
<init-param>
<param-name>cors.allowed.headers</param-name>
<param-value>Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization</param-value>
</init-param>
</filter>
Of course, I'm not sure why the authorization header is not by default allowed by the CORS filter.
The first thing I would try is to set your common headers for your http requests that angular dispatches, by inserting the following config block on your module:
.config(function($httpProvider){
$httpProvider.defaults.headers.common = {};
$httpProvider.defaults.headers.post = {};
$httpProvider.defaults.headers.put = {};
$httpProvider.defaults.headers.patch = {};
})
These are supposed to be set by default already, but I've found that I often have to do this manually in my config due to any overrides from other modules or internal angular bootstraping process.
Your CORS filter should be enough on the server side to allow these types of requests, but sometimes, you need to specify request methods in addition to your origins, as well as accepted content types. The tomcat docs have this advanced block, which addresses those.
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
<init-param>
<param-name>cors.allowed.origins</param-name>
<param-value>*</param-value>
</init-param>
<init-param>
<param-name>cors.allowed.methods</param-name>
<param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>
</init-param>
<init-param>
<param-name>cors.allowed.headers</param-name>
<param-value>Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers</param-value>
</init-param>
<init-param>
<param-name>cors.exposed.headers</param-name>
<param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value>
</init-param>
<init-param>
<param-name>cors.support.credentials</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>cors.preflight.maxage</param-name>
<param-value>10</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CorsFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
If the first doesn't work on it's own, try enhancing your filters, especially:
<init-param>
<param-name>cors.allowed.methods</param-name>
<param-value>GET,POST,HEAD,OPTIONS,PUT</param-value>
</init-param>
<init-param>
<param-name>cors.allowed.headers</param-name>
<param-value>Content-Type,X-Requested-With,accept,Origin,Access-Control-Request-Method,Access-Control-Request-Headers</param-value>
</init-param>
<init-param>
<param-name>cors.exposed.headers</param-name>
<param-value>Access-Control-Allow-Origin,Access-Control-Allow-Credentials</param-value>
</init-param>

Resources