In d3 version 3, I had this code, which worked great:
d3.html("http://google.com",function(frag){
console.log(frag);
});
That code doesn't work in version 4. So looking at the API and change log, I thought perhaps this:
d3.html("http://www.google.com").get(function(error,frag){ console.log(frag); });
But this doesn't work either. Does anyone have a working example of d3.v4 for d3.html?
Thanks
It's not a problem with d3. It's probably because the page you're requesting doesn't allow for CORS. Whether it's google.com or your server it should include Access-Control-Allow-Origin header to the response if you want to get it via an async call (XMLHttpRequest, aka AJAX) on a page located at different origin than the server.
As a proof see this codepen: http://codepen.io/LukaszWiktor/pen/OXQwRk?editors=0011
In case of missing CORS headers Chrome Dev Console shows following error:
Related
i am playing around with Postman to get some insight on how things work behind the curtain and ran into, what I believe, is an issue but wanted to ask before I create a new issue on GitHub.
I am intercepting the request from my browser to the same site using the Postman Interceptor to use the request values in the native app. I have cookies enabled and the site (the whole domain) whitelisted.
When I use the history to resend the same request that was captured I get an auth error that is caused by the fact that the cookies are not included in the request (found that out by checking the cURL code snippet). I believe the reason for that is, that the cookies are set under another sub domain than that the request is send to.
I will try to include some pictures to clarify. My question here is:
Am I missing something/did I set something up in the wrong way
or is this an issue and I should create an issue in the official Postman Github page
cURL request
Cookies in Postman Native App
you should see if cookie is being send not using code snippet but the console :
its indeed sending cookies ,
I used the apollo-server-lambda package to create my lambda function with the serverless framework, as we can see, everything went well.
https://28d1lielb9.execute-api.us-east-1.amazonaws.com/prod
Now I working to place graphql in the same subdomain as my application in CloudFront and I am getting the error GET query missing.
https://forms.ciro-maciel.me/g/p/
I did several tests with the path, but I was not successful.
When did we receive the message GET query missing?
How can I correctly configure my environment?
Thank you
try to understand the codes and note that a playground presentation is conditioned by the code:
const acceptHeader = event.headers ['Accept'] || event.headers ['accept'];
with a log of the CloudFront call make sure the Accept header was not passed to a source.
then in Behaviors, obtain a configuration to be able to pass this header, as you can see below.
CloudFront - Behaviors - Accept
Configured and working!
Thanks to Ciro Cesar Maciel.
I had to add the header as following:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Edit the origin and add the header:
I have a web app located on domain A which contains an iframe on domain B. The request to the src on domain B has some Set-Cookie headers. If i load this web app with Safari, or chrome, I can see the cookies set from the iframe request in developer tools. However, if i visit the same page on the iOS simulator (iOS 12), the cookies are not set and I get auth errors (due to missing cookies). I haven't had any luck finding anything online about this behaviour so I have no idea how to work around it. I feel like I must be missing something because this seems like it would be a giant missing feature.
Unfortunately, i haven't had time to setup a simple reproduction for this issue.
Any kind of advice would help.
The issue is with Safari iOS do not allow setting cookies from domain B, unless you "explicitly visit" B. Workaround is to visit the iframe domain and set blank cookie there, then bounce back to original A domain. Afterwards your "Set-Cookie" directives or whatever you use to set cookies will be allowed by iOS.
Check out this solution and discussion (also includes reproduction setup):
https://gist.github.com/iansltx/18caf551baaa60b79206
I'm working on an browser extension that authenticates with a remote server via XMLHttpRequests. In Firefox (59.0.2) I have the problem that the session cookie send by the server is not stored in the browser. When looking at the network traffic I get a Set-Cookie response from the server for every request:
Set-Cookie JSESSIONID=node01abks2u96hf84wt0i1uqwsb9879.node0;Path=/
but it seems that the cookie is never accepted or stored in the extension.
When looking at Chrome (where the extension is working) my extension includes this cookie in the request:
Cookie: io=jCX1X9rlaOhCqE0nAAAB JSESSIONID=node01abks2u96hf84wt0i1uqwsb9879.node0
However, this is not the case in Firefox. Why is Firefox is not including the cookie in the request? and why is it not storing the cookie?
UPDATE: as suggested I filed a bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1454806
Furthermore, I created a very minimal example addon that fails:
https://gitlab.com/czeidler/firefox-cookie-problem
Could somebody please let me know if that addon really should work? or am I doing something wrong? To trigger the problem open the debug view of the addon and select the network view. Then click the addon popup icon. This will trigger two requests to my server. The first reply contains a Set-Cookie header that is not reused in the second request.
I found the reason why it is not working. Firefox handles a request from the popup as a cross domain request and does not set the cookie for this reason. Not sure if Chrome and Firefox should behave the same here or which approach is the better one. Here is how I fixed this issue to make it work in both browsers:
On the server:
response.addHeader("Access-Control-Allow-Origin", request.getHeader("Origin"))
response.addHeader("Access-Control-Allow-Credentials", "true")
In the popup:
connection.withCredentials = true;
UPDATE 2:
I found the reason, but not a solution yet. This has to do with how safari browsers deal with the '#' when Cloudfront redirects HTTP to HTTPS. Safari ignores the hashtag, and apparently this is a bug that's existed in Safari for years. I'm not 100% sure this is my issue, but it seems to be. Still looking for a solution.
END UPDATE 2
For some reason I'm having trouble figuring out, Safari browsers (mobile and desktop) act differently from Chrome and Firefox when I refresh a page or try to access a route directly on my app.
I have a playlists route:
Router.map(function() {
...
this.resource("playlists", function () {});
...
});
I can hit the playlists route directly with rooturl.com/playlists on Chrome and Firefox and in the console logs, I see this:
Attempting URL transition to /playlists
When I try to hit the playlists route directly in Safari, I see this:
Attempting URL transition to /
Another strange thing is that when I use my localhost the transition is correct on all browsers including safari (mobile and desktop). This makes me think it has something to do with the production environment. I'm using AWS S3 and Cloudfront, but I'm not fully sure that has anything to do with this.
I can provide more information here if asked.
UPDATE:
When I use the fragment (followed by a '#') in the url, safari redirects correctly. So this redirects correctly:
example.com/#/playlists
But this does not:
example.com/playlists
Again, this problem only occurs in production, on AWS S3/Cloudfront. On localhost, Safari works as expected.
In my case, this was fixed by making sure the protocol is not switched from https to http at any point. Specifically, S3 was issuing a redirect over http while the original request was over https. This leads to Safari stripping the request from any (potentially) sensitive data.
Fixed it by adding https to our S3 redirect setup.