The widget only permits use on 127.0.0.1 and localhost. In case this doesn't work for you, let us know on GitHub.

[NanisTe]

We tried to use the widget in our online Kubeflow environment on our AWS Kubernetes Cluster. Unfortunately I got this message on running the widgets show function:

The widget only permits use on 127.0.0.1 and localhost.
In case this doesn't work for you, let us know on GitHub.

Could someone please explain the boundary conditions to run the widget?

Thanks
Best Sinan

[yGuy]

Well, as the error message states, the widget won't run when the page is served from a server that is different from 127.0.01 or localhost. This is obviously the case for your setup.

You may ask why?

This is because we want to prevent commercial usage where someone else is hosting the server/widget for you (and might even be charging you for using our free widget). This was a commercial, rather than a technical decision.

We do want to support common use-cases. The most common use-case obviously is to run the server on your own computer. We also recently allowed the usage of the widget in mybinder.org and once we have support for it implemented, we also want to support kaggle and google colab.

If you want us to consider your use-case, we would need more information. If you do not want to share this publicy, feel free to contact us via our contact form on https://www.yworks.com

Thanks.

[yGuy]

We are currently considering lifting the restriction and are looking for white listing of public jupyter notebook servers like kaggle, mybinder.org, etc.

If you know of a big domain that hosts jupyter notebook services and where the plugin doesn't run, feel free to drop a note, here, and we'll likely add it to our white list with one of the next releases.

[yGuy]

With the 1.4.2 release we enabled Visual Studio Code and google colab, as well as dominolab. myBinder should also still work.
Also HTML exports of the notebooks should now work, standalone.
Kaggle could work, however it seems Kaggle itself is broken and we were not able to get any custom widget to work, there.
GitHub unfortunately does not support custom widgets and we weren't able to get the widgets to work in the JetBrains products, either.

[TermeHansen]

I don't think I get this restriction. I my use case, I use Jupyterlab on a local calculation server within our company LAN. Why should we have this restriction from using this widget on our own servers or when working remote? This is the true beauty of jupyterlab for me, that I can work on the same instance of jupyterlab as long as I have a browser with access to my server...

What are my options in this use case?

[yGuy]

This is because we want to prevent commercial usage where someone else is hosting the server/widget for you (and might even be charging you for using our free widget). This was a commercial, rather than a technical decision.

I can see that you have installed the widget yourself in this case, but you could just as well share your notebook URL with someone else so that they can use your notebook with our widget like a SAAS solution; they might even charge you for that. We want to avoid this scenario. We want our users to be aware of the fact that they are using our (free as in beer) product. If you have an idea how we can avoid this scenario and detect that you as the user actually installed the widget yourself for free (and hence accepted the license terms), we are all open to this.

It seems you are a power-user with a custom jupyter server infrastructure. If you can help us detect this situation (mostly by looking at the URL that is shown in the browser), we will see what we can do.

Right now, it sounds as if this was a use-case that we would not want to restrict, so if this is a common use-case, we would need a way to detect it to "white-list" this.

Again, this is mostly a commercial/political decision which itself I do not want to discuss, here, and unfortunately you seem to run into the situation where our heuristic fails to detect your use-case. We would be happy to address the failure in the detection to make a use-case like this possible.

[yGuy]

What are my options in this use case?

If you need a workaround, right now, it might work to proxy your jupyter server to localhost - install a proxy on your machine and connect to your server via a proxy on some localhost port that forwards all the requests to the non-localhost server.

Or host your notebook on google colab, or mybinder, which are white-listed, too.

[runfourestrun]

I currently seem to be able to use this library via Google Colab notebook but can't use it in an Azure Machine Learning Studio Notebook (which feels weird that it works in one and not the other). I love this library and am disappointed it didn't work in the latter.

[fskpf]

Thanks for the details. Sounds like we could easily whitelist this in the upcoming days.

Just to be sure: The invalid host popup in the widget should tell you which location is actually blocked. It states

"You are running yFiles Graphs for Jupyter on [location] ..."

Can you send us the mentioned location? Then we know exactly what URL / domain we need to whitelist.

[runfourestrun]

@fskpf my bad.

You are running yFiles Graphs for Jupyter on https://{id}.eastus.notebooks.azuresandbox.ms.

[fskpf]

We just deployed a new version (v1.4.4) that should work on the mentioned domain.

Please try it again with the update. Let us know if it works for you since we cannot easily test it.

[yGuy]

@runfourestrun - did you find the time to check whether the white-listing worked? Thanks!

[runfourestrun]

@yGuy It did! Thanks for your responsiveness.

[yGuy]

I was just trying to use the widget on Amazon AWS Sagemaker. It's not yet white-listed.
My URL looked like this:
https://[somemagicnumbershere].studio.us-east-2.sagemaker.aws

I guess whitelisting sagemaker.aws should do it? (us-east-2 might be specific, although I am definitely close to that region). "studio" could also be checked...

[fskpf]

Whitelisted with v1.4.5.

[yGuy]

John Hopkins university has a hosted Jupyter Notebook installation at https://apps.sciserver.org/ - we should whitelist that one.

"You are running yFiles Graphs for Jupyter on https://apps.sciserver.org/."

[fskpf]

Allowed with v1.4.6.

[alexdashkov]

Hello,
Is it possible to whitelist the plugin for the Google's Vertex AI notebooks?
The URL looks like that https://[somemagicnumbersandletters].notebooks.googleusercontent.com

[yGuy]

Thanks for the issue. I agree - we will whitelist this. Please stay tuned for the next release!

[fskpf]

We allowed the mentioned URL pattern with v1.4.6.
If it still does not work, please provide us the "You are running yFiles Graphs for Jupyter on URL" message from the error popup in the widget.

[alexdashkov]

I've just tested with the new version and I can confirm that it works. Thanks!

[engg14000]

Hello @yGuy ,
Please whitelist the plugin for the Google's DataProc Jupyter notebooks?
URL format : https://<cluster_id>.dataproc.googleusercontent.com

[fskpf]

Allowed with v1.4.7.

[engg14000]

from yfiles_jupyter_graphs import GraphWidget
#shows empty widget
GraphWidget()

This yields below error
Error displaying widget : model not found

Any idea how to resolve this?

[fskpf]

Please try to restart Jupyter Lab (mandatory after installing a new widget). If this does not help, please open a new issue here where we can dig deeper.

[yGuy]

The lab and/or the kernel. The new widget and its dependencies need to be registered properly in the kernel and lab and depending on which ones where installed during the previous start, a restart might be required, unfortunately. I don't think we can improve the situation here, other than maybe improve the documentation. We have this mentioned in some places, but obviously you don't get to see this at runtime. Jupyter Lab's output could be more helpful, though.

[engg14000]

I did cluster restart and it helped. Thanks 👍

[craig-willis]

I work on a number of public research data infrastructure projects based on the Whole Tale platform where we would like to include support for the yfiles jupyter widget. Would it be possible to whitelist the following domains?

• wholetale.org
• htmdec.org

[yGuy]

I think we will whitelist wholetale.org. Thanks for suggesting it!

The "www.htmdec.org" looks pretty closed, though. Can you elaborate on how it is used and by whom? Feel free to contact us via our contact forms at yworks.com, if you don't want to disclose this information, here.

[craig-willis]

Thank you, @yGuy. Sorry - there is nothing at www.htmdec.org right now (we should correct that). You can find more information here:

• https://docs.htmdec.org/
• https://github.com/htmdec/

This is a deployment of the Whole Tale software stack for materials science research. The data is access controlled, but the software is public and funded by research grants.

[DylanShang]

Hello @yGuy
Please whitelist kuzu-lab.netlify.app

Kuzu-wasm is the WebAssembly version of Kuzu and is also the first WebAssembly database in the graph domain. With the help of JupyterLite, I created Kuzu-lab, enabling data science research with zero installation costs. All of the above projects are open source and are used for analysis in the graph data domain, with researchers from the University of New South Wales. By using yFiles Jupyter, we can enhance user interactivity and increase the visibility of yFiles Jupyter to a broader audience.

[fskpf]

I'll whitelist the URL with the next feature release (v1.8.0) which is planned for the end of this (or maybe the upcoming) week.

[DylanShang]

Thanks very much!