When I navigate to web.mysite.com, a static SPA hosted in S3, it has an iframe which has a src of mysite.com/some/path, which is a Spring Boot MVC application in Elastic Beanstalk. Both are behind Cloudfront distributions for HTTPS. This path is handled in the application with a custom resource resolver. This loads successfully, but inside the iframe content there is a script tag looking for mysite.com/some/path/thatsdifferent, handled by the same resolver.
This second request fails with a 403 and I cannot determine why. Navigating to the failing mysite.com/some/path/thatsdifferent directly in my browser or using postman succeeds with a 200 status. The server is configured to allow requests from web.mysite.com through CORS configuration (and there is no CORS-related error message) and Spring Security is configured to permitAll any requests to /some/** regardless of authentication. There is no response body or error message beyond the header x-cache: Error from cloudfront.
If I navigate to the-beanstalk-env-url.com/some/path, it loads the html and then successfully loads the content from the-beanstalk-env-url.com/some/path/thatsdifferent.
Requests to a few different but similar paths succeed. Going to a path which definitely 100% does not exists returns a 404.
The server logs show that the request is being successfully handled and Cloudfront is returning reasonable responses to the client. Looking at the Cloudfront logs simply reports a 403, without any additional information.
Almost 100% of Cloudfront 403 error articles and questions involve S3, which is not the part which is failing here.
Changing the Cloudfront distribution Allowed Methods from GET, HEAD to GET, HEAD, OPTIONS causes the requests directly to mysite.com/some/path/thatsdifferent to begin failing with invalid CORS request, this was fixed by whitelisting the Accept, Authorization, Host, Origin and Referer headers. This did not fix the underlying error.
Adjusting the logging for org.springframework.security doesn't log any extra information when a failing request occurs, my application security configuration is not what is causing the error.
After replacing Cloudfront with a load balancer on my environment in Route 53, the scenario works as expected, so the problem is definitely in Cloudfront.
The solution was to switch the Cloudfront Origin Protocol policy from HTTP Only to HTTPS Only.
I don't know why this mattered from the script file and not the html file, but I decided to test it out when I discovered that if I tried to connect to the Beanstalk environment URL via https, Chrome was warning me that the certificate being used was setup for the domain that was served by the Cloudfront distribution that was causing trouble.
Related
I am attempting to configure Swagger Authentication on my resource server, so that I can authenticate against my authorization server.
I have the resource and authorization servers separated. They are both starting up on my localhost with different ports.
Resource Server on port 8083
Authorization Server on port 8081
Whenever I attempt to "Authorize", there is a CORS issues.
I forked a project from another website to use as my testing grounds. Below is the forked project.
https://github.com/cbriarnold/oauth2-spring-boot-2.0.2
To test, once both the authorization server and resource server are started, do the following:
Go to http://localhost:8083/swagger-ui.html
Click on "Authorize" button
Click on "Authorize" button in dialog
If you have the developer tools open, you will see that there is the CORS error
Access to fetch at 'http://localhost:8081/oauth/token/' from origin 'http://localhost:8083' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.
The http status code associated with the above CORS error was 302.
So, I modify the source to try to permitAll (I know this is undesired from a security perspective, but I am just trying to figure out what is going on). I will receive the same CORS error, but with the https status code of 403. Code is found on the following branch.
https://github.com/cbriarnold/oauth2-spring-boot-2.0.2/tree/permitAll
Any suggestions?
I think you need to add #CrossOrigin(/*your hitting server*/) on your controllers
it's a chrome security check to see if your are permitted to talk with that server or not it sends an option request at first and if you're permitted it send your original request which is accessing swagger
if you want to make sure if that is a cross origin problem or not try to send that request via postman because postman send your request direct without option request at first
I am using Postal PIN Code API for getting Post Office(s) details search by Postal PIN Code in angular 5 application. Below is the url of the external API :
http://postalpincode.in/api/pincode/{**PINCODE}**
I am issuing a GET request from the application but it is giving me below error :
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access
Although this request is working perfectly fine from browser and postman. I understand that we need to configure our server with cross-domain policies for accepting cross-domain request but this is an external API and I don't have control over it. How can I resolve this issue?
Thanks in Advance !!
Best: CORS header (requires server changes) CORS (Cross-Origin Resource Sharing) is a way for the server to say “I will accept your request, even though you came from a different origin.” This requires cooperation from the server – so if you can’t modify the server (e.g. if you’re using an external API), this approach won’t work.
Modify the server to add the header Access-Control-Allow-Origin: * to enable cross-origin requests from anywhere (or specify a domain instead of *). This should solve your problem.
2nd choice: Proxy Server If you can’t modify the server, you can run your own proxy. And this proxy can return the Access-Control-Allow-Origin header if it’s not at the Same Origin as your page.
Instead of sending API requests to some remote server, you’ll make requests to your proxy, which will forward them to the remote server.
Here are a few proxy options.
Ref: https://daveceddia.com/access-control-allow-origin-cors-errors-in-angular/
I have set up SSO using weblogic on windows and Kerberos, It is working fine for the http pages, however I observed a strange behavior on https pages which requires CONFIDENTIAL setting for the transport, It works fine if I first access a page on http which is not configured as secured in web.xml(Transport-Gurantee as None) and then the https page.
But If I try to hit the https url directly which is configured with Transport-Gurantee as CONFIDENTIAL then it shows the Basic Auth Dialog and a 401 Unauthorized response, Looking at the logs I see that the Server responded with the WWW-Authenticate but browser showed the Basic Auth Dialog in response instead of getting the Authorize token.
Does anyone has any idea on what might be issue here, If there is any problem with the browser settings then it would not have worked irrespective of accessing the http url first.
I can see the following error log in weblogic console
Malformed request "Can not parse URI from http request". Request parsing failed, Code: -1
Found one of the link here
SPNEGO on IBM WebSphere Portal 6.1 with https
For my case it is weblogic 12c , I don't think reinstalling 12c is a valid solution for it
Ok I got it fixed , It turns out to be an issue with the browser configuration , the https://myserver.domain.com was not inside the intranet domain and the control to do that rests with the windows Admin team, once they added it , the https urls are also working fine.
I am a newbie to Heroku server. I found the default connection method is https.
If I switched to http, I will received the following errors when accessing
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin *** is therefore not allowed access.
Any idea to enable http access?
The problem here appears to the same-origin policy. Seems that some of your requests are mixed between plain http and https which all modern browsers interpret as having different origins.
Without seeing additional debug information, I'm going to guess the main page is still loaded via https, but the page assets (images, javascript, css etc.) are now loaded via http.
Assuming this is correct, the first step is to ensure the main html page is loaded using the same origin (same domain, same scheme (http or https) etc.).
I'm getting this error when trying to make an ajax request in a custom module:
XMLHttpRequest cannot load https://www.vossmarket.com/index.php/shoppinglist/index/showLists/product/4294/form_key/6erZKqom1ynOWDKI/qty/1/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.vossmarket.com' is therefore not allowed access.
I'm assuming the problem is that I am calling https from the http, but I'm not able to figure out why it is calling the https. I've turned off https in the magento config (I changed secure_base_url to http://vossmarket.com and I turned Use Secure URLs in Frontend to "no"). Now all links stay http, but when I visit my custom module, it is still redirecting (302) to https. This happens to every link http://vossmarket.com/shoppinglist (my custom module), any other route stays http, but any route that hits my module in any ways 302s to https
Any ideas what might be happening or the best way to fix it?
Have you tried putting a file called crossdomain.xml in your web root (accessible by both http and https), ie at http(s)://vossmarket.com/crossdomain.xml
This should help define that cross site origin is allowed between http and https.
In your case, I think the custom module is upset about being accessed over http and is sending the 302 to your browser, so it would be a case of studying the controller action of the custom module to figure out why it is forcing https (instead of asking Magento what the secure URL is).
Actually, if you try this crossdomain.xml you will need the browser to request https out of the http loaded page otherwise I think you will still get the 302 redirect - but with crossdomain.xml in place you should be able to XMLHttpRequest from http://vossmarket.com to https://vossmarket.com
But, you know, often there is good reason for https so I think you should understand why https is being forced and also I don't know about that XML secure="false" - does it really mean an https request is returned over http? I hope not but I don't know.
For more information read up on CORS although your 'cross domain' is http crossing to https.