namsral / multipass

Better authentication for HTTP
BSD 3-Clause "New" or "Revised" License
73 stars 4 forks source link

fresh installation not working #17

Closed slowkow closed 7 years ago

slowkow commented 7 years ago

Expected behavior

When I go to test.mydomain.net I expect to see a login page.

Observed behavior

When I go to test.mydomain.net I actually see all of the content, and there is no authorization screen anywhere.


Could I please ask for some tips on how to get this working?

I selected multipass from this page and downloaded the caddy binary:

https://caddyserver.com/download

Here's my Caddyfile:

test.mydomain.net {
  root /var/www/test.mydomain.net
  multipass {
    handles myusername@gmail.com
    mail_from "Multipass <no-reply@mydomain.net>"
  }
}

I run these commands to start the server:

cd /var/www/test.mydomain.net
caddy -conf=/etc/caddy/Caddyfile -log stdout

The output contains:

Activating privacy features... done.
multipass for https://test.mydomain.net is initialized
slowkow commented 7 years ago

I tried to follow your instructions rather than the instructions on the caddy page:

https://caddyserver.com/docs/multipass

I ran this:

go get github.com/namsral/multipass

Next, I had to manually install each dependency one by one to get this command to run:

go install github.com/namsral/multipass/cmd/multipass

Next:

sudo setcap 'cap_net_bind_service=+ep' `which multipass`

Finally, run the server with multipass instead of caddy:

multipass -conf=/etc/caddy/Caddyfile -log stdout

Hooray! Now I can see the login screen!

However, as soon as I submit the form, the multipass command crashes with this error:

multipass -conf=/etc/caddy/Caddyfile -log stdout
Activating privacy features... done.
2017/01/18 20:33:08 ignoring invalid mail template at /var/www/test.mydomain.net
multipass for https://test.mydomain.net is initialized
https://test.mydomain.net
2017/01/18 20:33:09 https://test.mydomain.net
http://test.mydomain.net
2017/01/18 20:33:09 http://test.mydomain.net
WARNING: File descriptor limit 1024 is too low for production servers. At least 8192 is recommended. Fix with "ulimit -n 8192".
panic: dial tcp 127.0.0.1:2525: getsockopt: connection refused

goroutine 13 [running]:
panic(0xa2de00, 0xc42018c550)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/namsral/multipass/services/email.runMTA(0xc420057260, 0xc4201194a0, 0xf, 0x0, 0x0, 0x0, 0x0, 0x9dd)
        /home/ubuntu/go-workspace/src/github.com/namsral/multipass/services/email/email.go:181 +0x35a
created by github.com/namsral/multipass/services/email.NewUserService
        /home/ubuntu/go-workspace/src/github.com/namsral/multipass/services/email/email.go:124 +0x2e1
slowkow commented 7 years ago

@mholt I just want to loop you in to this issue, just in case you have some tips.

namsral commented 7 years ago

This is a dup of #12 which was fixed with ea98f1d.

Unfortunately the fix has not yet trickled down to the Caddy webserver builds. A workaround is to add resources / to the multipass directive in your Caddyfile:

test.mydomain.net {
  multipass {
    resources /
    ...
  }
  ...
}
slowkow commented 7 years ago

Thanks for the tip!

Indeed, I see the login screen with the caddy executable when I add resources / to the Caddyfile.

However, the login screen does not work when I add resources /authorized instead of resources /. I have a folder called 'authorized' that I'd like to protect.

slowkow commented 7 years ago

One more comment.

If I do not have smpt_addr 127.0.0.1:2525 in my Caddyfile, then the login screen is disabled. I must include that directive to get a login screen.

Unfortunately, when I do include the directive, I get a new problem described in #18.