I’m running nitrogen on inets, configured to serve *two* ports, an ordinary ip port and an ssl port. That works fine—nitrogen serves the same information on both ports, but if I want to interact securely with the site then I can do it on the ssl port.
What I would LIKE to do is to disable the parts of the site that really require secure access, when I visit it through the non-encrypted port. But to do that, I need to find out from nitrogen which port the request being served came through. Does anyone know of a way to do that?
On Wed, Mar 14, 2012 at 9:20 AM, John Hughes <john.hug...@quviq.com> wrote: > I’m running nitrogen on inets, configured to serve *two* ports, an ordinary > ip port and an ssl port. That works fine—nitrogen serves the same > information on both ports, but if I want to interact securely with the site > then I can do it on the ssl port.
> What I would LIKE to do is to disable the parts of the site that really > require secure access, when I visit it through the non-encrypted port. But > to do that, I need to find out from nitrogen which port the request being > served came through. Does anyone know of a way to do that?
Thank you! That sounds like just what I need. I didn't realise wf:socket() would tell me the socket type--very useful!
I am actually using Apache as a reverse proxy to forward port 80 to 8000 already... my problem is I want to access the *same page* (i.e. same .erl file) through http and https, and see different options in each case. I suppose I could make two different pages, but that would be more complex and less maintainable however I did it (code duplication or a more complex module structure). I'm not sure nginx would really solve that problem for me.
Though I personally prefer to throw nginx in front of Nitrogen deal with that kind of routing (URL-based, anyway).
-Jesse
On Wed, Mar 14, 2012 at 9:20 AM, John Hughes <john.hug...@quviq.com> wrote: > I’m running nitrogen on inets, configured to serve *two* ports, an > ordinary > ip port and an ssl port. That works fine—nitrogen serves the same > information on both ports, but if I want to interact securely with the > site > then I can do it on the ssl port.
> What I would LIKE to do is to disable the parts of the site that really > require secure access, when I visit it through the non-encrypted port. But > to do that, I need to find out from nitrogen which port the request being > served came through. Does anyone know of a way to do that?
On Wed, Mar 14, 2012 at 19:46, John Hughes <john.hug...@quviq.com> wrote: > Hi Jesse,
> Thank you! That sounds like just what I need. I didn't realise wf:socket() > would tell me the socket type--very useful!
> I am actually using Apache as a reverse proxy to forward port 80 to 8000 > already... my problem is I want to access the *same page* (i.e. same .erl > file) through http and https, and see different options in each case. I > suppose I could make two different pages, but that would be more complex and > less maintainable however I did it (code duplication or a more complex > module structure). I'm not sure nginx would really solve that problem for > me.
Depends where you want routing decisions to be handled. In front webserver (nginx) or in Erlang application?
If in a-la-nginx, simply configure access rules for both http and https virtualhosts individually. If nitrogen case, I would think about doing the Erlang application on a single http port, and using a real web server to make "real" 80 and 443. And append some kind of header in each case (X-port: 80/443 for instance).
I don't know the exact syntax for web servers, but should be easy to figure it out.
Further, if you need to find out if the client is connecting with ssl, you can add an nginx (or apache) rule to add a custom header for clients connecting through ssl, then check for the existence of the header in nitrogen.
The main reason I'd do that is to minimize the number of servers with the ssl cert installed. Though in the long run, for performance, you can switch all static files to be served from nginx/apache, and leave all the dynamic stuff to nitrogen/inets.
But if this isn't exactly a high performance app, then most of this of overkill anyway.
-- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 www.sigma-star.com @jessegumm On Mar 14, 2012 8:39 PM, "Motiejus Jakštys" <desired....@gmail.com> wrote:
> On Wed, Mar 14, 2012 at 19:46, John Hughes <john.hug...@quviq.com> wrote: > > Hi Jesse,
> > Thank you! That sounds like just what I need. I didn't realise > wf:socket() > > would tell me the socket type--very useful!
> > I am actually using Apache as a reverse proxy to forward port 80 to 8000 > > already... my problem is I want to access the *same page* (i.e. same .erl > > file) through http and https, and see different options in each case. I > > suppose I could make two different pages, but that would be more complex > and > > less maintainable however I did it (code duplication or a more complex > > module structure). I'm not sure nginx would really solve that problem for > > me.
> Depends where you want routing decisions to be handled. In front > webserver (nginx) or in Erlang application?
> If in a-la-nginx, simply configure access rules for both http and > https virtualhosts individually. > If nitrogen case, I would think about doing the Erlang application on > a single http port, and using a real web server to make "real" 80 and > 443. And append some kind of header in each case (X-port: 80/443 for > instance).
> I don't know the exact syntax for web servers, but should be easy to > figure it out.
