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