Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for HTTPS #89

Open
ChandaniM123 opened this issue Jan 21, 2019 · 8 comments
Open

Support for HTTPS #89

ChandaniM123 opened this issue Jan 21, 2019 · 8 comments

Comments

@ChandaniM123
Copy link

I am trying to use this server-proxy to talk to an application that accepts only https requests(requires SSL). Is there a way to update this to support https ?

@yuvipanda
Copy link
Contributor

Heya! Good question! I don't see why not. We can have a 'https' field in the config that can be set to 'true' optionally to support https. Would love patches! :)

@rcthomas
Copy link
Contributor

Hi @ChandaniM123 @yuvipanda I think we need to do this too. I'm thinking should we actually have configuration options for key, cert, and CA?

@yuvipanda
Copy link
Contributor

@rcthomas Yeah, that sounds like a good way to do that. Happy to review a PR

@rcthomas
Copy link
Contributor

Hey @yuvipanda I've made some progress on the HTTP handlers. I can at least make the proxy talk to various Dask components over SSL. It's not perfect but I think the remaining issue I have there on the HTTP handler side I will be able to work out. (Some certificate verification problem on the Dask dashboard.)

I'm also wondering if we should set up the default to be a check for the internal SSL components from JupyterHub. That is, something like:

keyfile = Unicode(
        os.getenv("JUPYTERHUB_SSL_KEYFILE", ""),
        help="SSL key, use with certfile",
        config=True
)

This may be a too-complicated default. A user could simply put that os.getenv() into their config, instead of us deciding for them that the above default scheme is the way they should be doing it.

The more looming thing is the websocket handler stuff, it's failing right now which I expected, and I am wondering if you had any pointers or orientation on the websocket side of things that it would be good to know before I start hacking.

@yuvipanda
Copy link
Contributor

Yeah, I think to begin with asking users to put os.getenv is probably the way to go.

I think @ryanlovett added most of the websocket stuff, so might have more pointers.

I am very excited you are working on this, @rcthomas!

@rcthomas
Copy link
Contributor

Thanks! OK, I may actually have gotten it working with websockets too. Now to test some more and clean up!

@PhML
Copy link

PhML commented Jan 6, 2023

@rcthomas What is the status of this issue ? Are you still working on it ?

@rcthomas
Copy link
Contributor

rcthomas commented Jan 6, 2023

@PhML no, and I think the reason I stopped pushing is that my motivating use cases evaporated. Not sure whether anyone else wants to pick it up and carry it forward, I am sure the PR I submitted is out of date. More sets of eyes on what was wrong there might help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants