search

mailslurper / mailslurper

Local, web-based mail server application. Slurp mails into oblivion!
MIT License
1.42k stars 184 forks source link

Hard to run behind nginx #92

Closed frioux closed 4 years ago

frioux commented 6 years ago

Mailslurper apparently cannot be configured to assume that it's not the root of your web server. Mailslurper tries to talk directly to the api port, instead of trying to talk to another directory in the web server.

bburton commented 6 years ago

Would suggest renaming this issue to, Enhance Mailslurper so the web interface can run in a folder.

For certain testing environments, it may require configuring Mailslurper to run behind a reverse proxy such as Nginx or Apache because it's not possible to expose the Mailslurper server directly to users. For this to work, Mailslurper needs to support a new option wwwContext or wwwPath where a specified path such as /mailslurper can be specified. This will enable Mailslurper to be configured behind a reverse proxy.

frioux commented 6 years ago

:man_shrugging: I ended up going a different direction, feel free to modify the ticket as you see fit :)

atmaniak commented 6 years ago

Wich direction ? :)

frioux commented 6 years ago

MailHog; already works for this use case out of the box. Feel free to use our fork at https://github.com/ZipRecruiter/MailHog.

atmaniak commented 6 years ago

Yes mailHog is fine but has a major problem : if mail contain an attachment, the json for loading messages is getting really big very quickly ...

adampresley commented 6 years ago

I'm curious, how exactly are you trying to set this up? Nginx on the front end with it setup to reverse proxy to which part of MailSlurper? The WWW front-end, or the service API? There are two HTTP listeners registered.

atmaniak commented 6 years ago

I've tried to install it behind nginx, it's impossible since all call to the service API is done to localhost:8085 directly.

hexlax commented 6 years ago

Same issue - was going to reverse proxy it behind Nginx, yet it seems the HTTP Service calls in the WWW frontend are hardcoded for "localhost" despite changing the service address in config.json?