Re: Want to customise the tomcat's session logic
On Mon, Nov 2, 2009 at 5:03 AM, Pid p...@pidster.com wrote: On 02/11/2009 10:06, S Arvind wrote: Hi Tomcat developers, Bascially my requirement is ability to control the session sharing in browser. Till now we maintained each application as differnet context but pointing to same doc-base. So different web application will be running on a same code to control the session sharing between different application . But now we want to run in same context as one application but control the session sharing. So i planned to customise session creation n management of the tomcat to our requirements to add some value to *path*attribute in session. Is this possible? I'm not sure your question is very clear, perhaps if you are able to make your question clearer someone will be able to help. If I understand correctly, you want to combine apps under a single context, but you still want some control over data in session, perhaps using a 'path' within the session object to store different values for different 'apps.' I know next to nothing about session management infrastructure in tomcat, but I happened to notice another mail o the list that mentioned the SessionManager which is specified in context.xml (I think). Based on that small piece of information, I'm guessing that you could provide your own SessionManager, which is likely responsible for creating new sessions and managing existing sessions. If so, it seems likely that you can manage sessions any way you'd like. For instance, whenever the session object is accessed, you could first inject the current 'path' for the request based on attributes in the request object, which would cause all attributes to be set with that path prefix in the session during that request. Documentation for the SessionManager object is here: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html
Re: trouble with connector configured to receive from SSL accelerator
Is it possible that sessions aren't persistent when switching between connectors. The proxyPort attribute on the connector did fix my problem, but I've discovered that logging in over an https connection only works if I click the remember-me checkbox, which sets a cookie on the client and stores some state in a db which can associate the cookie with the identity of the user. If I don't use remember me, the authentication occurs when connected via the secure connector and the user's identity is stored in the session, but when the system switches back to the other connector, it fails to find the authorization info in the session, so it redirects right back to the login page via https. I suspect the session cookie is being set as https-only, so it doesn't get passed back when accessing via http. Is there any way to correct this behaviour? I'll confirm momentarily. On Tue, Oct 13, 2009 at 1:00 AM, Sam Gendler sgend...@vid.me wrote: That looks like it will work, but it doesn't explain why the connector would think port 80 was appropriate. I could see port 8090 showing up, but given that the scheme is https and there was no port number in the request, surely it should have resolved that to port 443 instead of port 80? It just seems like a bug to me. It does look like proxyPort can be used to force it to 443, though, so that will work. On Tue, Oct 13, 2009 at 12:19 AM, Peter Crowther peter.crowt...@melandra.com wrote: 2009/10/13 Sam Gendler sgend...@vid.me: That method uses request.getScheme(), to retrieve https (correct) and request.getServerName() to get the correct host name. It then calls request.getServerPort(), which incorrectly returns the value of 80. [...] What do I need to do to get the request to correctly return 443 as the port when a request arrives on the connector without any port in the url or Host header? The keyword to look for is Proxying - your SSL front-end is proxying the SSL connector for you. http://tomcat.apache.org/tomcat-6.0-doc/config/http.html shows connector attributes of proxyHost and proxyPort, which I think will do exactly what you want. Hope this helps! - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: trouble with connector configured to receive from SSL accelerator
That looks like it will work, but it doesn't explain why the connector would think port 80 was appropriate. I could see port 8090 showing up, but given that the scheme is https and there was no port number in the request, surely it should have resolved that to port 443 instead of port 80? It just seems like a bug to me. It does look like proxyPort can be used to force it to 443, though, so that will work. On Tue, Oct 13, 2009 at 12:19 AM, Peter Crowther peter.crowt...@melandra.com wrote: 2009/10/13 Sam Gendler sgend...@vid.me: That method uses request.getScheme(), to retrieve https (correct) and request.getServerName() to get the correct host name. It then calls request.getServerPort(), which incorrectly returns the value of 80. [...] What do I need to do to get the request to correctly return 443 as the port when a request arrives on the connector without any port in the url or Host header? The keyword to look for is Proxying - your SSL front-end is proxying the SSL connector for you. http://tomcat.apache.org/tomcat-6.0-doc/config/http.html shows connector attributes of proxyHost and proxyPort, which I think will do exactly what you want. Hope this helps! - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: trouble with connector configured to receive from SSL accelerator
No. That is by design. The session ID is almost as valuable as the password. If you need SSL to protect the password, you should use SSL to protect the session ID. Well, that's fairly application specific, but the argument has also been done to death elsewhere. Workaround is already in place.
trouble with connector configured to receive from SSL accelerator
[quickie synopsis] A request arriving on a connector configured for scheme=https and with secure=true is generating absolute redirect urls with scheme=https and port = 80 (https://localhost:80/path.html) because incoming request was on 443 and didn't have an explicit port in the Host header. [/quickie synopsis] I have a the standard connector configured on port 8080. I'm using an ssl accelerator (stunnel, for the purposes of debugging this) to talk to a 2nd connector which is configured to listen on port 8090. I added secure=true and scheme=https to the Connector tag of the second connector, but it is otherwise identical. The accelerator is configured to listen on port 443 and talk to port 8090. The redirectPort of both connectors is set to 443. If I connect to a resource, via stunnel, the connection correctly tunnels through 443 to port 8090. Unfortunately, If the resource needs to construct a redirect URL, after logging in to my app for example, the Connector goes badly wrong. I've gone through the code in the debugger and it correctly gets a True response from request.isSecure(). Because the request is secure and the response must also be secure, it can construct a standard redirect url, so it calls response.sendResponse(/path.html). That method eventually needs to construct an absolute url, which is does via the toAbsolute() method of org.apache.catalina.connector.Response. That method uses request.getScheme(), to retrieve https (correct) and request.getServerName() to get the correct host name. It then calls request.getServerPort(), which incorrectly returns the value of 80. I assume it does this because there is no port specified in the Host header, since the request is arriving on the default https port of 443, and there is a bug which causes it to assume the default port is port 80, even though the connector is configured to be secure and use https scheme. The code which constructs the url always appends :port to the hostname unless the port matches the default port for the scheme, and since 80 != 443, it winds up constructing a redirect url of https://localhost:80/path.html. Needless to say, this is totally incorrect. There is nothing listening on port 80 at all. I could understand if the connector were to return a redirect url to its own listen port of 8090. I don't think it would be correct, but it would at least make some sense. But picking up port 80 when nothing is listening to port 80 and the request isn't an http request without a port has to be a bug (or at least a missing configuration option that doesn't seem to be in the documentation anywhere). What do I need to do to get the request to correctly return 443 as the port when a request arrives on the connector without any port in the url or Host header? My two connectors are configured as such: Connector compressableMimeType=text/html,text/xml,text/javascript,text/css,application/x-amf compression=on compressionMinSize=2048 connectionTimeout=2 enableLookups=false noCompressionUserAgents=gozilla, traviata port=8080 protocol=HTTP/1.1 redirectPort=443/ Connector compressableMimeType=text/html,text/xml,text/javascript,text/css,application/x-amf compression=on compressionMinSize=2048 connectionTimeout=2 enableLookups=false noCompressionUserAgents=gozilla, traviata port=8090 secure=true scheme=https protocol=HTTP/1.1 redirectPort=443/ [cringe]I'm not using 6.0.20 yet. This is 6.0.18, but I couldn't find any reference to a bug fix in 19 or 20. It is a big deal to go to a new server version, and I'd rather avoid the work if I can. I'll test on 6.0.20 as soon as I send this mail, but I am really hoping for a suggestion for how to fix this on 6.0.18[/cringe]
Re: trouble with connector configured to receive from SSL accelerator
For what it is worth, I confirmed that the same issue exists with the latest 6.0.20 release. I also confirmed that if I set up SSL to run on a non-standard port (anything but 443), it works perfectly, because the port number is correctly picked up from the Host header rather than being left at the incorrect default of 80 when no port is specified in the url. On Mon, Oct 12, 2009 at 9:59 PM, Sam Gendler sgend...@vid.me wrote: [quickie synopsis] A request arriving on a connector configured for scheme=https and with secure=true is generating absolute redirect urls with scheme=https and port = 80 (https://localhost:80/path.html) because incoming request was on 443 and didn't have an explicit port in the Host header. [/quickie synopsis] I have a the standard connector configured on port 8080. I'm using an ssl accelerator (stunnel, for the purposes of debugging this) to talk to a 2nd connector which is configured to listen on port 8090. I added secure=true and scheme=https to the Connector tag of the second connector, but it is otherwise identical. The accelerator is configured to listen on port 443 and talk to port 8090. The redirectPort of both connectors is set to 443. If I connect to a resource, via stunnel, the connection correctly tunnels through 443 to port 8090. Unfortunately, If the resource needs to construct a redirect URL, after logging in to my app for example, the Connector goes badly wrong. I've gone through the code in the debugger and it correctly gets a True response from request.isSecure(). Because the request is secure and the response must also be secure, it can construct a standard redirect url, so it calls response.sendResponse(/path.html). That method eventually needs to construct an absolute url, which is does via the toAbsolute() method of org.apache.catalina.connector.Response. That method uses request.getScheme(), to retrieve https (correct) and request.getServerName() to get the correct host name. It then calls request.getServerPort(), which incorrectly returns the value of 80. I assume it does this because there is no port specified in the Host header, since the request is arriving on the default https port of 443, and there is a bug which causes it to assume the default port is port 80, even though the connector is configured to be secure and use https scheme. The code which constructs the url always appends :port to the hostname unless the port matches the default port for the scheme, and since 80 != 443, it winds up constructing a redirect url of https://localhost:80/path.html. Needless to say, this is totally incorrect. There is nothing listening on port 80 at all. I could understand if the connector were to return a redirect url to its own listen port of 8090. I don't think it would be correct, but it would at least make some sense. But picking up port 80 when nothing is listening to port 80 and the request isn't an http request without a port has to be a bug (or at least a missing configuration option that doesn't seem to be in the documentation anywhere). What do I need to do to get the request to correctly return 443 as the port when a request arrives on the connector without any port in the url or Host header? My two connectors are configured as such: Connector compressableMimeType=text/html,text/xml,text/javascript,text/css,application/x-amf compression=on compressionMinSize=2048 connectionTimeout=2 enableLookups=false noCompressionUserAgents=gozilla, traviata port=8080 protocol=HTTP/1.1 redirectPort=443/ Connector compressableMimeType=text/html,text/xml,text/javascript,text/css,application/x-amf compression=on compressionMinSize=2048 connectionTimeout=2 enableLookups=false noCompressionUserAgents=gozilla, traviata port=8090 secure=true scheme=https protocol=HTTP/1.1 redirectPort=443/ [cringe]I'm not using 6.0.20 yet. This is 6.0.18, but I couldn't find any reference to a bug fix in 19 or 20. It is a big deal to go to a new server version, and I'd rather avoid the work if I can. I'll test on 6.0.20 as soon as I send this mail, but I am really hoping for a suggestion for how to fix this on 6.0.18[/cringe]
