[erlang-questions] Nitrogen on several ports

26 views
Skip to first unread message

John Hughes

unread,
Mar 14, 2012, 10:20:15 AM3/14/12
to erlang-q...@erlang.org
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?
 
John

Jesse Gumm

unread,
Mar 14, 2012, 12:13:50 PM3/14/12
to John Hughes, erlang-q...@erlang.org
Hi John,

You can get the socket from Nitrogen and from the socket determine its type:

In code that could be something like

is_ssl() ->
Socket = wf:socket(),
is_tuple(Socket) andalso element(1,Socket)=:=sslsocket.

Though I personally prefer to throw nginx in front of Nitrogen deal
with that kind of routing (URL-based, anyway).

-Jesse

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

John Hughes

unread,
Mar 14, 2012, 3:46:54 PM3/14/12
to Jesse Gumm, erlang-q...@erlang.org
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.

John

Motiejus Jakštys

unread,
Mar 14, 2012, 9:38:41 PM3/14/12
to John Hughes, erlang-q...@erlang.org, Jesse Gumm
On Wed, Mar 14, 2012 at 19:46, John Hughes <john....@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.

Motiejus Jakštys

Jesse Gumm

unread,
Mar 14, 2012, 11:09:07 PM3/14/12
to Motiejus Jakštys, erlang-q...@erlang.org

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

Reply all
Reply to author
Forward
0 new messages