I have a TC 5.5 fronted by Apache2/mod_jk. Two SSL sites on different ips, one for users, one for admins. The admin one is apache password protected. Each apache ip virtual host uses a different worker to talk to TC on a different port in a different service. for example <Service name="User"> <Connector scheme="https" secure="true" address="127.0.0.1" port="10004" debug="0" useURIValidationHack="false" protocol="AJP/1.3"/> <Engine name="Standalone" defaultHost="User" debug="0"> <Host name="User" debug="0" appBase="webapps/SomethingUser" unpackWARs="false"> <Context blahblah/> </Host> </Engine> </Service> <Service name="Admin"> <Connector scheme="https" secure="true" address="127.0.0.1" port="10005" debug="0" useURIValidationHack="false" protocol="AJP/1.3"/> <Engine name="Standalone" defaultHost="Admin" debug="0"> <Host name="Admin" debug="0" appBase="webapps/SomethingAdmin" unpackWARs="false"> <Context blahblah/> </Host> </Engine> </Service> The problem, and it may be intended behavior, is that if you connect to ip1 and spoof your Host header as 'Admin', apache correctly routes the request (jk in debug says it connects via 10004) to TC via the User worker, but then TC appears to match the virtual host name in a different service and serves admin content getting around Apache's password protection. Via browsing a lot of bugs tonight I'm aware of the useIPVHost element which I could probably use to lock each host to the host apache intended, but this can't be intended behaviour. Can it? Across Service tags? Why would you ever need more than one service or connector then? Hopefully at the very least this will spur a note in the docs. if it is intended, as this is potentially dangerous. LMK if you need anything else to reproduce.
If you have suggested text for the note in the docs that you want, please attach it to this item and I'll gladly look at it, commit it as relevant.
Note in the docs? This has to be a bug, no? Should a connector of a service be able to access a host in another service? If yes, this is insane, if not you've got a bug.
(In reply to comment #2) > Note in the docs? This has to be a bug, no? > Should a connector of a service be able to access a host in another service? If > yes, this is insane, if not you've got a bug. Well, I guess it's insane then ;-). Multiple <Service /> tags is deprecated. However, if you don't name your Engines the same name, then the mapping should work as you expect it to.
(In reply to comment #3) > (In reply to comment #2) > > Note in the docs? This has to be a bug, no? > > Should a connector of a service be able to access a host in another service? > If > > yes, this is insane, if not you've got a bug. > > Well, I guess it's insane then ;-). > > Multiple <Service /> tags is deprecated. However, if you don't name your > Engines the same name, then the mapping should work as you expect it to. So are you saying that Engines across different services end up merged or visible to each other if they have the same name? If so I'd put that in the manual. I only ask because it causes a bit of a security problem. If you connect via Apache-httpd and think you can rely on a connector/engine either matching a host defined inside it, or defaulting to the default host inside it, you get a nasty shock if it happens to find a match on a totally different application somewhere else, especially if you thought that application was secured. :( Thanks for the prompt reply.
I have updated the docs. The update will be in 5.5.21 onwards.