First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having.
Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated & encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. thanks -anton On Thu, 2004-04-01 at 13:32, Bill Barker wrote: > ----- Original Message ----- > From: "Anton Ushakov" <[EMAIL PROTECTED]> > To: "Tomcat Developers List" <[EMAIL PROTECTED]> > Sent: Wednesday, March 31, 2004 10:59 PM > Subject: Re: Coyote's ServerSocketFactory problem > > > > Alright, thanks Bill. I have nothing against Tomcat5 and indeed the > > socketFactory="my.factory" attribute works. But is there any way to pass > > custom parameters to the factory from the conf file? With a <Factory> > > element it was possible but with a single attribute am I out of luck? > > All this IntrospectionUtils business is confusing... > > > > The way this works is that all of the <Connector> attributes are passed on > to the Protocol. In the case of the Http11Protocol, the attributes are then > passed on to the SocketFactory (via calling the setAttribute method of > o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your > parameters on the <Connector>, and they will end up passed to your > SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles > this for the default SSL connector. > > > > > On Fri, 2004-03-26 at 18:03, Bill Barker wrote: > > > ----- Original Message ----- > > > From: "Anton Ushakov" <[EMAIL PROTECTED]> > > > To: "Tomcat Developers List" <[EMAIL PROTECTED]> > > > Sent: Friday, March 26, 2004 4:24 PM > > > Subject: Re: Coyote's ServerSocketFactory problem > > > > > > > > > > Should I make a bug entry for this? I wanted to get someone from the > > > > tomcat dev team to see if I was missing something before flagging this > > > > as a bug. > > > > > > > > > > The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and > it > > > would probably should be for 4.x as well except for the fact that it is > > > still required to set SSL attributes. This means that anything > involving > > > this SocketFactory will just get marked as WONTFIX. > > > > > > Passing the socketFactory attribute on to the Protocol might be > something > > > (except for the fact that it is working in 5.x means it may not get a > lot of > > > attention :). > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > ______________________________________________________________________ > This message is intended only for the use of the person(s) listed above as the > intended recipient(s), and may contain information that is PRIVILEGED and > CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or > distribute this message or any attachment. If you received this communication in > error, please notify us immediately by e-mail and then delete all copies of this > message and any attachments. > > In addition you should be aware that ordinary (unencrypted) e-mail sent through the > Internet is not secure. Do not send confidential or sensitive information, such as > social security numbers, account numbers, personal identification numbers and > passwords, to us via ordinary (unencrypted) e-mail. > > > ______________________________________________________________________ > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
