finally solved: Windows Auth via IIS6 proxied to mongrel

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.

Ralf Vitasek 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).