Jupyterhub cross origin requests

[y2kbowen]

I have read the documentation but still having an issue with jupyterhub cross origin requests. I am running jupyter 4.3.0

I am making a request from my web application which when running under test has the origin http://localhost:5000. I am making the call from the client code to log into jupyterhub with the call:

POST http://10.7.135.5/hub/login HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/json, text/plain, */*
Referer: http://localhost:5000/home
Accept-Language: en-US
Origin: http://localhost:5000
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393
Content-Length: 23
Host: 10.7.135.5
Connection: Keep-Alive
Pragma: no-cache

username=kenb&password=

This will return a cors exception on my browser. So I read this issue (issue 79) and updated the c.NotebookApp.allow_origin = '*' in my jupyter_notebook_config.py.

I am still having the same problem. I run JupyterHub in a container and I was attempting to make the change without rebuilding the image by logging in and updating configuration through a bash shell.

So, what reads this config file? Does JupyterHub read this file in addition to its own config? Here are the processes running in my container:

/opt/conda/bin/python /opt/conda/bin/jupyterhub --ip= --config=config/jupyterhub/jupyterhub_config.py

/opt/conda/bin/configurable-http-proxy --ip  --port 8754 --api-ip 0.0.0.0 --api-port 8755 --default-target http://127.0.0.1:8081 --error-
target http://127.0.0.1:8081/hub/error

/opt/conda/bin/python /opt/conda/bin/jupyterhub-singleuser --user=kenb --port=56840 --cookie-name=jupyter-hub-token-kenb --base-url=/user/kenb
 --hub-host= --hub-prefix=/hub/ --hub-api-url=http://127.0.0.1:8081/hub/api --ip=0.0.0.0 --notebook-dir=notebooks --NotebookApp.default_url=/lab --debug --disable-user-config

Does jupyterhub have its own config for the login or maybe the proxy? I did stop and restart the jupyterhub process and I killed my single user jupyter document process. It is running in this view because I am able to get the code to run if I run chrome with --disable-web-security --user-data-dir

Thanks for any input.

$PATH:
        /opt/conda/bin
        /opt/conda/bin
        /root/hadoop-2.7.2/bin
        /root/hadoop-2.7.2/sbin
        /root/spark-2.1.0-bin-fluxcapacitor/bin
        /root/apache-maven-3.3.9//bin
        /usr/local/sbin
        /usr/local/bin
        /usr/sbin
        /usr/bin
        /sbin
        /bin

sys.path:
        /opt/conda/bin
        /opt/conda/lib/python35.zip
        /opt/conda/lib/python3.5
        /opt/conda/lib/python3.5/plat-linux
        /opt/conda/lib/python3.5/lib-dynload
        /opt/conda/lib/python3.5/site-packages
        /opt/conda/lib/python3.5/site-packages/setuptools-23.0.0-py3.5.egg

sys.executable:
        /opt/conda/bin/python

sys.version:
        3.5.3 |Continuum Analytics, Inc.| (default, Mar  6 2017, 11:58:13)
        [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]

platform.platform():
        Linux-4.4.0-71-generic-x86_64-with-debian-stretch-sid

which -a jupyter:
        /opt/conda/bin/jupyter
        /opt/conda/bin/jupyter

pip list:
        anaconda-client (1.6.2)
        appdirs (1.4.3)
        bleach (1.5.0)
        cffi (1.9.1)
        clyent (1.2.2)
        conda (4.3.14)
        cryptography (1.7.1)
        cycler (0.10.0)
        decorator (4.0.11)
        entrypoints (0.2.2)
        findspark (1.0.0)
        html5lib (0.999)
        idna (2.2)
        ipykernel (4.5.0)
        ipython (5.3.0)`

[minrk]

Unlike the single-user notebook application, JupyterHub doesn't have configuration to disable cross-origin security features. Only token-authenticated requests can be made cross-origin.

[y2kbowen]

Thanks for the reply. I want to followup to make sure I understand.

The request I am making is for login
http://10.7.135.5/hub/login

This call is to JupyterHub and not the single user instance. Since JupyterHub doesn't have a way to set cross-origin allow values then I can't login to get the token and since I don't have a token I cannot login. Is there another way that people are using to login as part of another application?

What I want to do is start a document with data created from another web application. JupyterHub is hosted in a container while my application is hosted somewhere else.

[mogthesprog]

@minrk

I'm trying to do disable cross origin features since i'm sitting behind a reverse proxy. I've used the c.NotebookApp.allow_origin config, which probably didn't help as you pointed out above.

Is it really not possible to disable this check in the hub?

I'm seeing this issue only when trying to use a notebook or the terminal:

Jul  7 10:34:57 ceng-sxdb-sxdb-vm jupyterhub: [W 2017-07-07 10:34:57.146 morganj zmqhandlers:159] Blocking Cross Origin WebSocket Attempt.  Origin: https://ceng-sxdb-sxdb-vm.ceng-sxdb.dunnhumby.cloud, Host: ceng-sxdb-sxdb-vm:8083
Jul  7 10:34:57 ceng-sxdb-sxdb-vm jupyterhub: [W 2017-07-07 10:34:57.147 morganj log:47] 403 GET /user/morganj/terminals/websocket/2 (::ffff:10.0.5.2) 2.14ms referer=None

[mogthesprog]

@minrk

any ideas?

[mogthesprog]

@y2kbowen

The solution in my case was to use the spawner notebook extra args option (see below) to disable cross origin verification in the spawned notebook... Maybe it can help you too.

c.Spawner.args = ['--NotebookApp.allow_origin=*']

[willingc]

Closing this issue as resolved. Please feel free to leave an issue at jupyter/help or leave a comment requesting this issue be reopened. Thanks to all!

[cloutiertyler]

@y2kbowen Were you ever able to work this one out? I'm having the same issue here.

[ihleonard-c3]

Same problem here. Any updates? @willingc I don't think this issue was ever resolved, and it should be reopened.

[colingoldberg]

I am having this problem, and I agree with @ihleonard-c3 that this issue should be reopened. I added the configuration c.Spawner.args = ['--NotebookApp.allow_origin=*'] but this made no difference - it still was rejected.

[minrk]

There's a little confusion, since two unrelated issues are reported here. Allowing cross-origin access to running notebook servers certainly does still work via c.Spawner.args. Please report that as a separate bug if you are still affected by it. It is likely an issue with a particular Spawner, as the default Spawner does work with this config in JupyterHub 0.8.

Cross-origin requests (with token) still doesn't work in the Hub, but #1539 fixs this.

I've made a test that enables cross-origin on both the Hub and notebook server, and steps through a few requests on each.

Cross-origin requests for the Hub can be enabled with (this will require >= 0.8.2):

c.Spawner.args = [f'--NotebookApp.allow_origin={origin}']
c.JupyterHub.tornado_settings = {
    'headers': {
        'Access-Control-Allow-Origin': origin,
    },
}

but that only gets you so far, because you still need to get the token in the first place.

As for the root of the original request, where the goal is an external service that wants to authenticate users with the Hub and then access the API, the answer will be OAuth. Right now, we have everything in place for this except:

1. allowing registration of external OAuth applications (OAuth is currently confined to internal authentication in 0.8)
2. adding OAuth scopes, so that OAuth tokens can be used to access specific endpoints (OAuth is currently restricted to identifying users only, not making API requests)

[willingc]

As for the root of the original request, where the goal is an external service that wants to authenticate users with the Hub and then access the API, the answer will be OAuth. Right now, we have everything in place for this except:

• allowing registration of external OAuth applications (OAuth is currently confined to internal authentication in 0.8)
  -adding OAuth scopes, so that OAuth tokens can be used to access specific endpoints (OAuth is currently restricted to identifying users only, not making API requests)

@minrk Will 0.9 address this?

[minrk]

We got part one (external oauth applications), but not part two (oauth scopes) because we need to implement a confirmation page to allow users to confirm granting access to take actions on their behalf.

[prerakmody]

So I wrote up a gist with instructions on how to abate this issue

It contains info on

1. Installing jupyterhub
2. Configuring nginx
3. Configuring jupyter-extensions

[robnagler]

I have a different but related problem: can't control JupyterHub from Jupyter when I'm running in a tunneled environment. The error is:

Blocking Cross Origin API request.  Referer: https://localhost:8443/hub/home, Host: localhost/hub/

The code is making the assumption about the port (that it is always the default 80 or 443), which I don't think it can do. A site might be configured with a reverse proxy
on a non-default port. It should be possible to specify this port (or '*') in the config so check_referer`can watch for this port.

[sysang]

It's quite late. but any way in case of anyone would be directed by Google later on. My circumstance, I followed this instruction to set up my Jupyter notebook behind nginx proxy: https://jupyter-docker-stacks.readthedocs.io/en/latest/using/recipes.html#running-behind-a-nginx-proxy.

I focused on nginx configuration to overcome the problem, so I found this instruction: http://oskarhane.com/avoid-cors-with-nginx-proxy_pass/.

It helped!.

[randy3k]

@robnagler I have actually the problem that you have mentioned. My nginx reverse proxy is running on a different port than 443. How did you fix your issue?

[randy3k]

I found a fix.

proxy_set_header Host $host:$server_port;

[meeseeksmachine]

This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:

https://discourse.jupyter.org/t/get-origin-of-the-request-in-notebook-config-py/7054/2

[manics]

I'm closing this as this has expanded to cover several separate issues, some of which were fixed.

[agates4]

@y2kbowen

The solution in my case was to use the spawner notebook extra args option (see below) to disable cross origin verification in the spawned notebook... Maybe it can help you too.

c.Spawner.args = ['--NotebookApp.allow_origin=*']

Note that if you're using KubeSpawner, you'll want to use these two lines:

    c.KubeSpawner.cmd = 'jupyterhub-singleuser'
    c.KubeSpawner.args = ['--ip=0.0.0.0', '--NotebookApp.allow_origin=*']

Providing the cmd config is required because without it, KubeSpawner will ignore those args. The --ip=0.0.0.0 is required, so that the spawned pod will bind to its host, and thus can be accessible by another pod in the cluster (this config is also provided by default, but any args provided through c.KubeSpawner.args will override the defaults, thus needing us to provide it manually)