Correct the ports in docker-compose file

[Nebucatnetzer]

No description provided.

[Nebucatnetzer]

Fixes #76

[mickael-kerjean]

Thank you for the pull request. I agree there's some mistakes in here but there's a few things I'm not a fan in your commit:
Binding to port 80 gives the impression HTTP is recommended but that would be suicide. If anybody intercept your cookie, he'll be able to connect to the service on your behalf. Can you change it to: 8334:8334?

A proper setup would need some sort of reverse proxy that isn't included in the docker compose file yet and configure with SSL. WIP

[Nebucatnetzer]

Okay I've corrected the port now.
I have all my servers behind a reverse proxy because I only have one IP address that's why I didn't really think about it. Either port will work for me.
Could the SSL be configured manually? In my network all internal connections are plain HTTP. The reverse proxy then servers the wildcard cert for all of them.

[mickael-kerjean]

I have all my servers behind a reverse proxy because I only have one IP address

I got the same kind of config

Could the SSL be configured manually? In my network all internal connections are plain HTTP. The reverse proxy then servers the wildcard cert for all of them.

I do exactly the same. For my particular config which seem the same as yours, I don't see a point in having SSL inside the application. I might be wrong but as I see it, if the reverse proxy is owned, so as the applications that run throught it.

[Nebucatnetzer]

For small networks that's true. If you have a bigger network it makes sense to have all the traffic encrypted. E.g. in a company otherwise someone can sniff the traffic if he connects to the network.
It's however much more complicated to setup.

I reckon that depends on the setup and the attack doesn't it? I have all services running in a separate VM. If just the reverse proxy itself gets hacked then the other servers should be fine. If it's the application that gets hacked maybe only that server is at risk? However I don't really know enough about this to be sure.

[mickael-kerjean]

If you have a bigger network it makes sense to have all the traffic encrypted.

Fully agree, that's just not my setup as I only got 1 machine + 1 IP and all the services running as a container in the same machine where the reverse proxy is. For my particular use case, SSL inside nuage is overkill, the only way to sniff would be to own the machine, thus already have access to it. When I mean overkill it's just I'm too lazy to make it work as it wouldn't provide much benefits.

If someone is interested in making changes to add SSL inside nuage, it will be merge, I just don't have any need for this.

If just the reverse proxy itself gets hacked then the other servers should be fine.

Two things here:

• your server might be fine or not depending on what you have in there. I've see some servers at work with private key to connect to other services everywhere. It's common practise in my company.
• your services running on those server should be considered compromise. If I can put my hands on your reverse proxy, I should be able to redirect your users anywhere and steal their credentials

[Nebucatnetzer]

your server might be fine or not depending on what you have in there. I've see some servers at work with private key to connect to other services everywhere. It's common practise in my company.

I have them surely not on the proxy ;)

your services running on those server should be considered compromise. If I can put my hands on your reverse proxy, I should be able to redirect your users anywhere and steal their credentials

Ah that's a good point. Didn't think about the credentials.