Open unmaskz opened 7 years ago
@kieranwt94 Can you provide some sample of what you are google visualization for? ie. chart types, components, features. I'm not on the team, but the Google Visualization API can query spreadsheets in google drive, so I think they'll want to know whether you're doing that. If you are, then the call to Google Drive is legitimate and invoked by your application.
It would probably also help to provide at least some part of the url from the request that is being blocked.
@nbering Hi, we are pretty much using tables, corecharts (pie charts), controls and dashboards. The data we are pulling from microservices that pull data and construct the data table for it. We aren't using the google drive / spreadsheets and don't ever need to our data comes elsewhere. So is there anyway of disabling any part of the library that makes reference to google drive / google docs etc.
I'm not aware of any settings that affect things on such a low level, but I'm not a member of the team. I just like to help get to the root of the problem to save their time.
If I had to guess, I'd say that if you are using the toolbar component with your dashboards, that is most likely to call to a google drive address.
All that said, it would probably help to have some log item from the firewall with the exact thing that is being blocked. Without that, anything at all is speculation since the problem is not actually the library, it's the firewall doing what firewalls do: block requests.
@nbering On some of our forms that use the google charts they are only using corecharts for piecharts and even then they are getting blocked. It seems in one of the library files there is some sort of reference to webdrive or spreadsheets.
jsap_compiled_default_module.js contains:
Bja=/^(trix|spreadsheets|docs|webdrive)(-[a-z]+)?\\.(corp|sandbox)\\.google\\.com/,Cja=/^(\\w*\\.)
Could just be a red herring however.
If it is blocking based solely on a URL that is in the code, as opposed to a file that is being requested, it seems unlikely that you are going to be able to do without that reference. I believe the capability to query google spreadsheet content is built into the core like a DataTable, etc.
Is there no way for you to make an exception for this content for this firewall product?
Possibly, but I need to find out the exact url of the js file that is causing it to be blocked. It is quite difficult to work out what files it gets stopped at.
As Nicholas says, there are a few places Google Charts can make requests to places other than to get more packages of the library (on the gstatic server), but no requests should be made unless you use the code that would make those requests. So if you are not invoking a query, either directly or indirectly (e.g. by specifying the dataSourceUrl in a ChartWrapper), and not requesting Google Maps geocoding via one of the map-related charts, then there should be no additional requests.
So we all need to find out exactly what URL is being requested so we have a chance of figuring out where that could be coming from.
By the way, I hope you are using the latest versions of Google Charts via the new loader: https://developers.google.com/chart/interactive/docs/basic_load_libs
@dlaliberte Hi, we are not using any code that defines a different dataSourceUrl such as google docs simply just using JSON to create the dataArrayTables. I can confirm we are using the new loader for google charts as specified within the link you said. We are also not requesting Google Maps geocoding.
I've created a jsFiddle to show roughly what we are trying to do. We use active directories so only way to bypass the block on websense is to add users to the AD group that allows access to the category Google Drive (covers dropbox and any other file upload site).
http://jsfiddle.net/m748r1tk/6/
The files returned from the loader are the following:
I notice you are not quite using the new loader as documented. I see:
google.charts.load('visualization', '1', {...})
But fortunately, I added a workaround to make this work the same as:
google.charts.load('current', {...})
Nothing on the jsfiddle page looks out of the ordinary, though I am wondering about the load of https://ssl.gstatic.com/editor/button-bg.png which appears to be from code (the default_module) rather than via a css file, though I am not sure about that. I also don't see any css files being loaded with 45.1, but I do with 45 or 45.2. This is suspicious, but not related to the problem you are having.
In any event, if this is all you are doing, I don't see a problem. But you say this is roughly the same as what you are trying to do, so I would focus on what is different.
@dlaliberte Thanks for taking a look. I believe I was using a specific version on the live page as the current version had an issue regarding pagination.
There is no differences really. The jsFiddle has an array of values static where as the live has values pulled from a microserver that forms it into an array. Apart from that there is no differences that are obvious to me. It is quite a weird one.
It would be good to see a list of files and paths that get called through the loading of google charts.
Hi, We are currently using google visualization by loading it in via loader.js - however, the company I work for works behind a firewall with websense. Websense is set up to block any upload site e.g. google drive, dropbox. It seems the loader.js is stopping at a specific file being loaded due to references to either google maps or google drive which are blocked. Is there any solution for this?