Gracias Martin, probaré si lo que me dices me sirve. Thank you very much André, now I have understood the problem much better. Thank you for your explanation.
Analía. 2013/12/16 André Warnier <a...@ice-sa.com> > ANALIA DE PEDRO SANTAMARIA wrote: > >> I'm going to try to explain myself better. >> > > I believe that we understand what you seem to want to do, but that there > are some intrinsic problems with the way in which you are looking at this. > > > >> What I'm trying to do is create a permission system in Tomcat. This >> permission system must allow or avoid the next connections: >> - Receive from IP. The application with this permission only can accept >> connections (or receive information) from an IP. It can't send anything or >> connect to anywhere. >> - Receive All. The application with this permission can accept connections >> (or receive information) from any IP. It can't send anything or connect to >> anywhere. >> - Send and Receive IP. The application with this permission can accept >> connection and connect to an IP. >> - Send to IP. The application with this permission only can connect or >> send information to an IP. It can't receive information or accept >> connections from anywhere. >> - Send to All. The application with this permission can connect or send >> information to any IP. It can't receive information or accept connections >> from anywhere. >> >> > "Accepting connections from" and "processing HTTP requests from" are two > essentially different things, and happen at different levels/moments in > time. > "Connecting to" and "sending information to" is a third different and > independent thing. > > Roughly : > - a TCP connection is "accepted" at the Tomcat/Connector level, long > before anything starts reading on that connection to receive the actuall > HTTP request. > - then the HTTP request is read, and it is determined which application > (if any) should process that request > - and it is only after the above, that an application would (or would not) > process the request > > In other words, if you really want to "block connections" (or allow them) > from selected IP's, then this is something that happens before the target > application is even known, and it cannot be specific per application. > > On the other hand, when the connection has been accepted and the request > has been read and the target application has been selected, it is possible > at the level of the selected application, to check the source IP, and > reject (or accept) the request. > (But at this stage, not the connection anymore, it's too late for that). > > The second part concerns what the application can do, once it is running > to process a request. > > Tomcat has basically no knowledge of any incoming or outgoing connection > that the application itself may be setting up with any "third party". > Tomcat itself is not involved in such connections, and it has no way to > interfere with them. > That is the domain of the JVM which runs the application code, and it is > at that level that you can allow/disable such connections. > > > >> With the SocketPermission, I can avoid that one application connects to >> an >> specific IP or any IP (not granting SocketPermission "connect"). But if I >> try to avoid that one IP connects to the application (not granting >> SocketPermission "accept"), it doesn't restrict all connections. For >> example, I can connect to the application from a browser in another host. >> (I'm using the Security Manager in a correct way because it works with >> others permissions). >> >> If I add <Valve className="org.apache.catalina.valves.RemoteHostValve" >> allow="localhost"/> to the context.xml, I can restrict the previous >> example, but with this I restrict all connections, so it doesn't allow me >> to do what I want. >> >> If I combine the SocketPermission with the RemoteHostValve I can grant the >> first three permissions (or connections) in my list above. But I need to >> restrict the incoming connections (accept connections) to grant the last >> two. >> >> > Yes, and it is all perfectly logical that it would be that way, because of > where and when things happen. > > What I am trying to say, is that it is your requirements that do not fit > the reality of how things work. You are trying to combine, under one > artificial "permission name", things which are difficult to combine because > they happen at different levels and have different scopes. > > For example, if you do not grant to an application the SocketPermission > "accept", it means that this application cannot open it's *own* listening > socket and accept connections on it. But this concerns listening sockets > that your application would want to open on its own, and it is totally > distinct from (and has nothing to do with) the listening socket on which > Tomcat accepts HTTP requests (for this application and others). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
