I'm currently trying the Mapbox examples and notably this one.
When the example tries to get the GeoJSON points from the following code:
map.addSource("earthquakes", {
type: "geojson",
// Point to GeoJSON data. This example visualizes all M1.0+ earthquakes
// from 12/22/15 to 1/21/16 as logged by USGS' Earthquake hazards program.
data: "https://www.mapbox.com/mapbox-gl-js/assets/earthquakes.geojson",
cluster: true,
clusterMaxZoom: 15, // Max zoom to cluster points on
clusterRadius: 20 // Use small cluster radius for the heatmap look
});
I get the following error:
Blocking a Cross-Origin Request: The "Same Origin" policy does not
allow you to view the remote resource located at
https://www.mapbox.com/mapbox-gl-js/assets/earthquakes.geojson .
Reason: The CORS "Access-Control-Allow-Origin" header is missing.
I saw about similar problems what to add in http header but how to do it here?
This is up to mapbox. Their server is saying the origin from which you are querying this is not allowed by policy (check headers in the options request). Because their policy isn't supporting the Access-Control-Allow-Origin header, any requests made by XHR to mapbox.com must come from mapbox.com.
Now you could conceivably get around this by using a proxy server on a local VM to pretend you're on mapbox.com - using a HaProxy container, for example, on Virtual Box - and in its config setting up an ACL that points certain requests to mapbox.com to your code and the rest to mapbox.com's IP address. You would then use /etc/hosts to pass requests to mapbox to your VM instead and handle it from there. This is not a simple solution, I just thought it worth pointing out that it's possible.
Related
Getting this error:
Access to fetch at 'https://myurl.azurewebsites.net/Player/1' from origin 'http://localhost:19006' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
I'm not the first with this error, but I feel like I have tried everything that one can find through searching for the problem. I'm developing a web API with ASP.net core, that's supposed to communicate with my react-native frontend. Problem is, I cannot for the life of me get the connection to work.
In program.cs I have added
var MyAllowSpecificOrigins = "_myAllowSpecificOrigins";
builder.Services.AddCors(options =>
{
options.AddPolicy(name: MyAllowSpecificOrigins,
policy =>
{
policy.AllowAnyMethod();
policy.AllowAnyHeader();
policy.AllowAnyOrigin();
});
});
and
app.UseCors(MyAllowSpecificOrigins);
I have tried adding no cors to the method itself
[DisableCors]
[HttpGet("{id}")]
public List<Player> GetPlayers(int id)
{
return (from c in _context.Player.Take(1)
where c.PlayerId == id
select c).ToList();
}
I even deployed the server and database on Azure (I was supposed to sooner or later anyway) just hoping that would allow me to get it to work. The API runs fine if I visit the URL and run it through that one. It also works great if I host it locally and go through the web.
On Azure I've changed my cors settings to allow everything:
I can even access the API through expo web if I run it locally at the same time. But I need to be able to do it through my phone as well, or at least an android emulator. Neither of those works for neither a locally hosted server, or one that's on Azure.
How can I solve this?
Actually, shortly after setting my Azure cors settings, it did indeed start to work. Finally, I can at least demo it. Unfortunately, I still have no solution that solves it when hosting locally.
While testing the API definition of my Azure Function (within the portal) I get this CORS error:
This is a cross-origin call. Make sure the server at ***.azurewebsites.net accepts POST requests from functions.azure.com. Learn more
I verified that this is listed as a CORS allowed origin within the function settings:
https://functions.azure.com
Am I missing something?
I cannot reproduce this on my side.
I added the following to ALLOWED ORIGINS:
The output in the Azure portal:
I also test it by making a POST request to the function in the browser via jQuery:
If you want us to dive into this problem you may need to provide detailed steps to reproduce.
The problem turned out to be the API definition. CORS was working fine although that was indicated as the problem in the error messages. The missing piece in the API definition was
security: []
which was missing in the POST section. I guess the security entry is required even if it's empty. It would've been nice if there was a warning that this was missing.
I am using Videogular2 for azure content playback. The contents hosted on azure without DRM works perfectly. When I implement DRM protected content having token authentication gives CORS error. The error is thrown while fetching license from license server.
Following is my code
stream = {
source: 'http://xxxxx.streaming.mediaservices.windows.net/xxxxxxx/abc512kb.ism/manifest(format=mpd-time-csf)',
licenseServers: {
'com.widevine.alpha': {
serverURL: 'https://xxxxxx.keydelivery.westindia.media.azure.net/Widevine/?KID=xxxxx-ef40-87ed-b348-xxxxxx'
}
},
token: 'Bearer xxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
}
<video #media
[vgMedia]="media"
[vgDash]="stream.source"
[vgDRMLicenseServer]="stream.licenseServers"
[vgDRMToken]="stream.token"
id="singleVideo"
preload="auto" crossorigin
>
</video>
I got following error while fetching license from license server.
Response to preflight request doesn't pass access control check: The
value of the 'Access-Control-Allow-Origin' header in the response must
not be the wildcard '*' when the request's credentials mode is
'include'. Origin 'http://localhost:4300' is therefore not allowed
access. The credentials mode of requests initiated by the
XMLHttpRequest is controlled by the withCredentials attribute.
If I run it with disable-web-security of chrome then I call works perfectly.
Did any one face such issue while playing content from Azure Media.
Mandar -- Azure Media Services (AMS) origin sets the value of the 'Access-Control-Allow-Origin' header in preflight response as the wildcard ''. This works well with most players including our Azure Media Player, Roku and JW, and others. From the error, it seems Videogular2 does not work with AMS origin URL since, with credentials mode set to “include”, XMLHttpRequest in their dashjs does NOT allow wildcard “” as the value of “'Access-Control-Allow-Origin”.
Are you running the player from a single domain? If you are, we can set the request to include your incoming origin domain instead of the wildcard. Reach out to me at dwgeo at microsoft dot com and we can enable the feature on your account. Thanks.
I'm faced the same problem. Here is the Videogular2 source https://github.com/videogular/videogular2/blob/master/src/streaming/vg-dash/vg-dash.ts#L70
It work fine on same domain, but for different domain withCredentials=true is missing. after creating player on 70th line
this.dash = dashjs.MediaPlayer().create();
Should go this
this.dash.setXHRWithCredentials(true);
I hope it might help
The app I'm working on has a controller that issues templates to the front end (single page app). It's very basic, and simply consists of
#path = params[:path]
render template: "templates/#{#path}", layout: nil
Here my concern however is the direct use of the users input. Everything about this to me feels like it can be attacked with something as simple as path traversal. The route for this is
get "/templates/:path.html" => "templates#file", constraints: { path: /.+/ }, defaults: { format: 'html' }
I've tried multiple things to attempt a path traversal attack, such as
request /templates/path/to/../somewhere/else.html
request /templates?path=/path/to/../../something.rb
request /templates/index.html?path=/path/to/../../config/something.html
request /templates/path/../../../file.html
Fortunately, I haven't had any success with this. The requests that just start with /templates and don't specify anything after it, don't match the route thanks to the constraint so that is good.
It seems as though when that route is matched, rails doesn't allow you to override the path parameter through a url parameter, so I don't seem to be able to inject it there.
The ones that interest are the first and last examples above, where rails seems to internally be changing the requested URL before invoking the routes file. When I request /templates/path/to/../somewhere/else.html, my console output shows a request for /templates/path/somewhere/else.html. When I make a request for /templates/path/../../../file.html, the log shows a request for /file.html.
Am I missing something somewhere that will leave the app open to security issues, or is this just rails being sensible and protecting itself for me?
UPDATE
I've done some more digging, and if I try doing some URL encoding then I can cause the server to simply not respond at all. If I request /templates/%2e%2e%2f%2e%2e%2f%2e%2e%2ffresult.html then I just get an empty response with a connection: close header.
I assume that the parameter parser higher up in the rack is checking all urls for this type of attack? Regardless, my original question still stands. Am I missing something here?
I am using SproutCore to query a CouchDB database on Mac OSX (10.6.7), from a tutorial on NetTuts+ premium. The database name is microblog. The query resolve to this string:
"http://localhost:5984/microblog/_design/posts/_view/posts?descending=true"
If I type this query directly in the browser's address bar, I get a nice json answer. But through the SproutCore app, I get an error message:
405 Method Not Allowed
Why is that? would that be because SC is running out of :4020 and CouchDB out of :5984 ? Any ideas?
Because of Javascript cross-domain regulations you are not allowed to query any arbitrary URL from your browser. If you loaded your sproutcore page from localhost:4020, it's forbidden to contact any other host or port on the same host.
To overcome this problem you usually make your sproutcore host proxy to the backend. You can do this by including a proxy statement like the following in your sproutcore buildfile
proxy "/microblog", :to => "localhost:5984"
which will forward all request going to localhost:4020/microblog to your backend localhost:5984/microblog. As you can imagine this might lead to problems where you can't set the url in your sc application to the desired value, the common case might be that your sc application is also named "microblog" the above proxy directive would then cause your sc application url being overridden.
To fix that problem you can use another url in your sc application to contact the backend, e.g. /db and then use the url parameter in the proxy directive to rewrite the target url:
proxy "/db", :to => "localhost:5984", :url => "microblog"
All requests to localhost:4020/db will then be forwarded to localhost:5984/microblog and will no longer interfere with your sc application on localhost:4020/microblog.