after struggling for quite a while i finally solved my problem to use
windows authentication in my rails app.
maybe some of you are trying to achieve the same and documentation about
this is quite hard to find so i thought it’s a good idea to share this
here…
after i stopped trying to run my rails app directly on IIS (which never
REALLY worked) i tried the commercial ISAPI_Rewrite from helicon with a
RewriteProxy rule and my app running on mongrel with the
“reverse_proxy_fix” plugin.
after installing the ISAPI_Rewrite filter on the windows server you need
to
→ run “proxycfg.vbs -r” inside the installation folder “C:\Program
Files\Helicon\ISAPI_Rewrite”
→ edit the httpd.ini there and add a rewriteproxy rule like
RewriteProxy /test(.*) http://the_host_where_mongrel_runs:3000/$1
[I,U,D,A]
→ enable windows authentication in IIS and restart IIS (iisreset)
→ install the revers proxy fix via:
ruby script/plugin install
http://svn.napcsweb.com/public/reverse_proxy_fix
and enter the url where you want to run the app (e.g.
http://domain/test)
→ fire up mongrel
→ let IIS do the auth and harvest the name of the authenticated user
via request.env[‘HTTP_X_ISRW_PROXY_AUTH_USER’] and do some
authorizations or deny access as you like
→ be happy (at least i am now!!!)
i hope this is of help to someone
regards
neongrau
Looks like a great FAQ addition!
Okay…now do you have a set of rewrite rules for all of the non rails
generated links (such as straight javascript code) that the
reverse_proxy_fix plugin doesn’t handle? I’ll give you $100 for them!
We messed around with the IIS reverse proxy from salty pickle, but
there were some errors in its rewrite rules that I didn’t feel like
debugging today. It looks like you could add one line of code to their
logic in creating the proxy request to put the auth_user in the HTTP
headers.
I would caution anyone doing this, or any other reverse proxy solution,
to make sure that they don’t allow their mongrels to accept connections
from anything other than IIS. The HTTP header is rather easily faked.
On Dec 13, 12:38 pm, Ralf V. [email protected]
matt mcknight wrote:
Okay…now do you have a set of rewrite rules for all of the non rails
generated links (such as straight javascript code) that the
reverse_proxy_fix plugin doesn’t handle? I’ll give you $100 for them!
hmm i don’t have any such rules, all i needed was a RewriteCond to
distinguish the hostname where rails app runs from the other sites on
IIS and a single RewriteProxy rule. since i don’t have static/absolute
pathes in any of my javascript code everything just works.
can you give an example how those links look like that don’t work when
proxied?
We messed around with the IIS reverse proxy from salty pickle, but
there were some errors in its rewrite rules that I didn’t feel like
debugging today. It looks like you could add one line of code to their
logic in creating the proxy request to put the auth_user in the HTTP
headers.
haven’t seen or tried that saltypickle tool, as i stated i used the
commercial one from helicontech (so far just the 30 day trial) but the
prices for the full version are ok imho.
Ralf V. wrote:
can you give an example how those links look like that don’t work when
proxied?
Ha- I was so deep in the problem that I forgot what I was doing with
root paths. I had some links in the that begin with a “/”, and they
weren’t getting rewritten. Of course they all work perfectly with
Apache mod_proxy, so I just assumed it was a problem with the
ISAPI_Rewrite thing and I’d have to go and try to recreate some of
those rewrite rules from Apache. The obvious workaround is to use the
“…/…/” style links in the app, although those can be tricky if you
attempt re-use the code in things that live at different virtual
directory depths. Small price to pay for getting that request property
populated.
Thanks again for your post!
Matt
Matt:
If you use my reverse_proxy_fix plugin and make sure all your URLS in
Rails
use the built-in helpers, links work fine. Avoid doing any hard-coded
paths
(javascript_include_tag, link_to, stylesheet_link_tag) and my plugin
will
take care of directing traffic back around.
The main reason I wrote the plugin was to prevent the backend server
from
being exposed. to the user (the frontend server name and port are
prefixed
to all requests from the user side).