Currently the remoteappmanager.services.hub.Hub class authenticates users and calls to the remoteappmanager REST API by extracting the access token from the jupyter-hub-token-{user} cookie and injecting it into the Authorization header of any outgoing requests.
|
@gen.coroutine |
|
def verify_token(self, cookie_name, encrypted_cookie): |
|
"""Verify the authentication token and grants access to the user |
|
if verified. |
This relies on the JupyterHub cookies being visible on the client side by default (i.e. NOT HTTP secure), which introduces a security risk and also means that our authentication procedure is tightly coupled to JupyterHub's internals.
it's possible that this was simply a pragmatic development choice, as there may not have been any other way to handle authentication between the hub and the spawned application with early versions of JupyerHub (we are pinned at < 0.8.0).
However, since JupyerHub moved to issuing HTTP only cookies in v0.8.0, we will not be able to support any later versions of the package until this is resolved.
Currently the
remoteappmanager.services.hub.Hubclass authenticates users and calls to the remoteappmanager REST API by extracting the access token from thejupyter-hub-token-{user}cookie and injecting it into theAuthorizationheader of any outgoing requests.simphony-remote/remoteappmanager/services/hub.py
Lines 36 to 39 in 15c24cb
This relies on the JupyterHub cookies being visible on the client side by default (i.e. NOT HTTP secure), which introduces a security risk and also means that our authentication procedure is tightly coupled to JupyterHub's internals.
it's possible that this was simply a pragmatic development choice, as there may not have been any other way to handle authentication between the hub and the spawned application with early versions of JupyerHub (we are pinned at < 0.8.0).
However, since JupyerHub moved to issuing HTTP only cookies in v0.8.0, we will not be able to support any later versions of the package until this is resolved.