proxying and port exposure..

[mgliewe]

I know this has been discussed manytimes before, and probably this is the wrong platform here..
apoligies.

I'd like to use che as a 'remote reference dev' platform when on road; but it lacks authorization and tls support. Using a vpn helps, but i don't always carry a laptop..

Auth and tls could be provided by a reverse proxy, but..
Thats not so easily done, because each workspace opens its own port to listen on.

I might be blond, but what i was thinking.. We're talking http (and websockets) here, aren't we?

So, couldn't we just configure our proxy to translate https://xxx/PORTn/anything into http://host:PORTn/anything and let the proxy do the hard work?
So, translate a REST-like url into port assignments?

One would have to adapt all url references given from the workspaces into appropriate REST-like urls.

Could this be easily done, and, would this even be feasable?

As an alternative one could develop a simple tranparent proxy, filtering all ins&outs between webproxy and docker-instances and just replace all url-reference just on text basis...
something like
sed s#http://\([^:]+\)[:]\([0-9]+\)#http://$1/$2#g

any suggestions, or am i totally wrong?

[edit: attached a quick diagram about what i was thinking of]

[monaka]

I've not tested yet but it will be resolved simply by using a forward proxy.
For more information, google with word "nginx $scheme://$http_host$request_uri".

@wernight 's hack also may give you some hints.

[wernight]

#1560 is a similar issue with a discussion about how to do this properly.

[mgliewe]

after spending a weekend fiddling with che and websockets and xhr and port assignments and proxying..

i realized that the codenvy fork (https://github.com/codenvy/codenvy) seems to do exactly what i wanted in the first place, actually quiet the same way i thougth i would have attempted to implement it.

therefore i'lll consider this issue closed for now.

[TylerJewell]

Cool!

But please be aware that Codenvy's code is not open source. We do publish the code, but it's bound a Fair Source 3 license. It's a cool license which lets you use some of the code under certain restrictions.

[mgliewe]

[..] not open source.

yup, realized that, but the 'fair license' scheme is just right for me.. I'll just use it for myself on road as a fallback for now. Maybe share & develop some ideas with a partner on a live system.

(i'm using c9.io stuff in lxc containers for that right now, I'm thrilled to see how different this will feel)

[TylerJewell]

That exact reason - for scenarios like you describe - is why we went with a fair source license.

[wernight]

Wait what?! This is about Che, not about Codenvy. It may be closed for Codenvy but it's not done here, unless you expect people to just not use Che and use Codenvy only.