Re: Android 5.0 SSL handshake failure
On 01/22/2015 04:19 AM, Mark Thomas wrote:
On 22/01/2015 00:12, Matthew Mah wrote:
On 01/21/2015 03:24 PM, Christopher Schultz wrote:
Have you tried a plain-old HTTPS connection? No Websocket?
I just tried HTTPS using
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
try {
try {
InputStream in = new
BufferedInputStream(urlConnection.getInputStream());
byte [] buffer = new byte[1024];
in.read(buffer);
Log.i(TAG, new String(buffer));
}
catch(Exception e){
}
String cipherSuite = urlConnection.getCipherSuite();
Log.i(TAG, connected? + cipherSuite);
}
There is currently no content being served (only the websocket), but the
network trace shows a successful TLSv1.2 handshake. This should mean the
certificates and cipher suites are fine, but there is a problem with
some interaction between Android 5.0 and the Tyrus websocket
implementation.
Huh? Tyrus WebSocket is nothing to do with Tomcat.
Mark
Tyrus is running on a client trying to negotiate a SSL connection with
Tomcat. At this point, I am confident there is a bug either in Android
or in Tyrus and not in the Tomcat configuration, so we can cease
discussion on this topic here.
I think the most logical next step is to try a different
websocket implementation.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Android 5.0 SSL handshake failure
On 22/01/2015 00:12, Matthew Mah wrote:
On 01/21/2015 03:24 PM, Christopher Schultz wrote:
Have you tried a plain-old HTTPS connection? No Websocket?
I just tried HTTPS using
HttpsURLConnection urlConnection = (HttpsURLConnection)
url.openConnection();
try {
try {
InputStream in = new
BufferedInputStream(urlConnection.getInputStream());
byte [] buffer = new byte[1024];
in.read(buffer);
Log.i(TAG, new String(buffer));
}
catch(Exception e){
}
String cipherSuite = urlConnection.getCipherSuite();
Log.i(TAG, connected? + cipherSuite);
}
There is currently no content being served (only the websocket), but the
network trace shows a successful TLSv1.2 handshake. This should mean the
certificates and cipher suites are fine, but there is a problem with
some interaction between Android 5.0 and the Tyrus websocket
implementation.
Huh? Tyrus WebSocket is nothing to do with Tomcat.
Mark
I think the most logical next step is to try a different
websocket implementation.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 22:40, Shaun Morton wrote:
We will be creating a .jsp and putting it in a .war for you. Should be
tomorrow.
The issue is confirmed. We are working on the fix and a new 8.0.x
release now.
Mark
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Mark Thomas [mailto:ma...@apache.org]
Sent: Wednesday, January 21, 2015 4:00 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8.0.17 output buffer issues
On 21/01/2015 21:51, Shaun Morton wrote:
Sorry no, it happens on both connectors, 8080(HTTP) and 8443(HTTPS).
The 8080 connector is the default out of the installation. I try to stick
to defaults for trouble shooting purposes.
I must confess I suspected the two were related as well when I read your
mail. Since you are being far more responsive that the OP that filed that
bug, my current plan is to fix the issue you are seeing and then evaluate BZ
57476 in light of what we discover the root cause of this issue is.
I will say that 8.0.18 is likely to appear fairly soon after we track this
one down.
So, my question to you is this. With a clean 8.0.17 install, that is the
easiest way to reproduce this bug? Ideally, if you could provide the simplest
possible JSP that triggers this that would be great. (Since we are assuming
the reports are linked, just attach it to that BZ report.)
Cheers,
Mark
Shaun Morton
Legal Files Software
217-726-6000 Ext. 341
sh...@legalfiles.com
www.legalfiles.com
-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, January 21, 2015 3:45 PM
To: Tomcat Users List
Subject: Re: Tomcat 8.0.17 output buffer issues
Shaun,
On 1/21/15 4:23 PM, Shaun Morton wrote:
After upgrading from Tomcat 8.0.15 to Tomcat 8.017 our web software
was not loading completely in the end users web browser. The server
side was processing everything but never fully getting to end user.
We see that the response is not complete via Developer mode in IE.
Does it look at all like this:
https://issues.apache.org/bugzilla/show_bug.cgi?id=57476 ?
-chris
After much research through the Tomcat 8.0.17/8.016 Change Log we
could not find anything specific on this nor anything on the web.
After some trial and error we came up with a solution, but not an
acceptable solution for all our customers.
If I add the following to either our web.xml or Tomcats default
web.xml for the
servlet-classorg.apache.catalina.servlets.DefaultServlet/servlet-c
l
ass
we are working again:
init-param param-nameoutput/param-name
param-value64000/param-value /init-param
Basically we are looking for why we have to increase the output
buffer for 8.0.17 and if there is something else we can do to not
specify the output buffer size. Why the default output buffer size
is no longer working with Tomcat 8.0.17. This is the first time we
have ran into this issue with Tomcat.
80% of our customers use Tomcat and it is what we recommend from a
business standpoint.
We also think but can't be 100% that this is causing the issue when
the .java is getting complied: } catch (java.lang.Throwable t) { if
(!(t instanceof javax.servlet.jsp.SkipPageException)){ out =
_jspx_out; if (out != null out.getBufferSize() != 0) try { if
(response.isCommitted()) { out.flush(); } else { out.clearBuffer(); }
} catch (java.io.IOException e) {} if (_jspx_page_context != null)
_jspx_page_context.handlePageException(t); else throw new
ServletException(t); } } finally {
_jspxFactory.releasePageContext(_jspx_page_context); } } }
If we add this to our .jsp it fixes it: out.flush();
OS: Windows 2008R2, Windows 2012, Windows 2012R2, Windows 8.1 (all
64Bit) Java: JDK 8u25, JDK 8u5, JDK 7u17, JDK 7u11 Browser: IE 10 and
IE11 (only browser we support) Tomcat: 8.0.17 (Tomcat 8.0.15 was
completely uninstalled and directory deleted before install of
8.0.17)
I apologize up front as I am new to this support email group.
Shaun Morton
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail:
Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
On 22/01/2015 16:12, Leonid Rozenblyum wrote:
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
br /
User Principal: %= request.getUserPrincipal() % br/
%
if (request.getUserPrincipal() != null ) {
%
User is authenticated, allow to set session attribute
%
request.getSession().setAttribute(markerAttribute, markerAttributeValue);
}
else {
%
User is a guest. No setting of any session attributes.
%
}
%
You need to remove the session attribute if the user is not authentication.
Tomcat's SSO is working as expected. You are, of course, free to
extend/patch it if you prefer.
Mark
br /
Marker Attribute from session: %=
request.getSession().getAttribute(markerAttribute) %
On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
I think I could reproduce my problem also on experimenting with your
examples!
I went exactly by your steps but my JSP is an extended version of
yours ( I add it to attachment )
In the ROOT/test.jsp I added code to set a session attribute if the
user principal is not null.
I expect that after logging out via another application (using SSO) my
session attribute won't be there (my expectation of SingleSignOff is
complete session invalidation).
However it's not the case : after logging out in security/protected
the session attribute is still kept (while UserPrincipal is null).
Complete scenario:
- request ROOT/test.jsp
- no authenticated user
- no marker attribute in session
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- marker attribute is shown from session.
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
However - the marker attribute is STILL in session of ROOT webapplication.
For us it means that the session is NOT invalidated correctly.
Thanks for your feedback and detail scenario you sent, I think it
helped discover a probable bug...
On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
Hello!
I tried 8.0.17 (previously I had 8.0.15) and we still have the same
problem with same possible workaround.
I'll go through your examples, try them and compare what's the difference.
On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote:
On 20/01/2015 08:10, Leonid Rozenblyum wrote:
Thank you, Mark!
I spent some time stepping through the code using a default Tomcat
install with the following changes:
- SSO Valve uncommented in server.xml
- test.jsp added to ROOT app that shows request.getUserPrincipal
- uncomment user definitions in tomcat-users.xml
Note that the examples app ships with a protected page that requires
authentication.
I see the following:
- request ROOT/test.jsp
- no authenticated user
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
So, in short, I am seeing the behaviour you expect to see. I'm doing
this with 9.0.x (trunk) but that should be the same as the latest 80.x
release.
A couple of things to check:
- are you using the latest 8.0.x release (8.0.17 - I need to send out
the announcement)
- Turn on debug logging for the Host where you added the SSO valve - you
should see debug messages from the SSO valve which will show when
sessions get created, destroyed etc.
Mark
On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas ma...@apache.org wrote:
On 16/01/2015 14:05, Leonid Rozenblyum wrote:
Hello Mark.
We do explicit forced expiration of http session in one of SSO enabled
apps (Application1 : session.invalidate() )
and it didn't cause session expiration in other Apps
(only workaround with adding security-constraint to other apps that I
mentioned above helped).
Tomcat version is 8.0.15. OS tested was both linux windows
Probably I need to prepare minimal test case since it looks like a bug,
right?
Yes to the possible bug. Thanks but no need at this point for the test
case. I'll take a look at what is going on.
Mark
On Fri, Jan 16, 2015 at 2:53 PM, Mark Thomas ma...@apache.org wrote:
On 15/01/2015 15:46, Leonid Rozenblyum wrote:
Hello.
I have 2 web-applications
Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
So doesn't As soon as the user logs out of one web application (for
example, by invalidating the corresponding session if form based login
is used), the user's sessions in all web applications will be
invalidated. ( this phrase is from official doc) imply that all
sessions are invalidated and thus attributes are cleared?
(and as I mentioned above : there is some workaround that looks like
forces Tomcat to work exactly like this).
On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas ma...@apache.org wrote:
On 22/01/2015 16:12, Leonid Rozenblyum wrote:
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
br /
User Principal: %= request.getUserPrincipal() % br/
%
if (request.getUserPrincipal() != null ) {
%
User is authenticated, allow to set session attribute
%
request.getSession().setAttribute(markerAttribute, markerAttributeValue);
}
else {
%
User is a guest. No setting of any session attributes.
%
}
%
You need to remove the session attribute if the user is not authentication.
Tomcat's SSO is working as expected. You are, of course, free to
extend/patch it if you prefer.
Mark
br /
Marker Attribute from session: %=
request.getSession().getAttribute(markerAttribute) %
On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
I think I could reproduce my problem also on experimenting with your
examples!
I went exactly by your steps but my JSP is an extended version of
yours ( I add it to attachment )
In the ROOT/test.jsp I added code to set a session attribute if the
user principal is not null.
I expect that after logging out via another application (using SSO) my
session attribute won't be there (my expectation of SingleSignOff is
complete session invalidation).
However it's not the case : after logging out in security/protected
the session attribute is still kept (while UserPrincipal is null).
Complete scenario:
- request ROOT/test.jsp
- no authenticated user
- no marker attribute in session
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- marker attribute is shown from session.
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
However - the marker attribute is STILL in session of ROOT webapplication.
For us it means that the session is NOT invalidated correctly.
Thanks for your feedback and detail scenario you sent, I think it
helped discover a probable bug...
On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
Hello!
I tried 8.0.17 (previously I had 8.0.15) and we still have the same
problem with same possible workaround.
I'll go through your examples, try them and compare what's the difference.
On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote:
On 20/01/2015 08:10, Leonid Rozenblyum wrote:
Thank you, Mark!
I spent some time stepping through the code using a default Tomcat
install with the following changes:
- SSO Valve uncommented in server.xml
- test.jsp added to ROOT app that shows request.getUserPrincipal
- uncomment user definitions in tomcat-users.xml
Note that the examples app ships with a protected page that requires
authentication.
I see the following:
- request ROOT/test.jsp
- no authenticated user
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
So, in short, I am seeing the behaviour you expect to see. I'm doing
this with 9.0.x (trunk) but that should be the same as the latest 80.x
release.
A couple of things to check:
- are you using the latest 8.0.x release (8.0.17 - I need to send out
the announcement)
- Turn on debug logging for the Host where you added the SSO valve - you
should see debug messages from the SSO valve which will show when
sessions get created, destroyed etc.
Mark
On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas ma...@apache.org wrote:
On 16/01/2015 14:05, Leonid Rozenblyum wrote:
Hello Mark.
We do explicit forced expiration of http session in one of SSO enabled
apps (Application1 : session.invalidate() )
and it didn't cause session expiration in other Apps
(only workaround
Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8
Chris, Embedded? Yes, I guess that it is. I'm sorry, I've worked with Tomcat in the past, but not much with this application, and I do not understand much about the architecture of this aspect of the application that I have inherited. I will check the Tomcat class and look for the unit tests to which you refer. Thank you very much. Terry From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 22, 2015 8:03 AM Subject: Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Terry, On 1/21/15 5:33 PM, Terry Medearis wrote: Greetings,I have inherited code that calls: org.apache.catalina.startup.Catalina.process(args). So... embedded? I now need to upgrade this code to Tomcat 8. Currently, we are using Tomcat 6. I have previously upgraded with no problems, but both Tomcat 7 and 8 do not have the .process method. I can not find any documentation as to what should be used in place of .process(args). I have tried: - Catalina.load(args) - Catalina.start() For both, the application failed with an error stating that the server could not be contacted. I'm sorry that I can not give more detail than that. I am counting on the idea that there must be some replacement for the .process() method that I am just not comprehending. If you know the replacement for org.apache.catalina.startup.Catalina.process(args) and could share it with me, I would be very grateful. You probably want to take a look at the Tomcat class, which has unified ans simplified a lot of the embedded setup for Tomcat. Many of the unit tests use the Tomcat class to construct and launch servers programatically, and so there are a wealth of examples available. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwRFIAAoJEBzwKT+lPKRY7xcP/RAcGeYA8GUBj+Arsija971V OthIf7SZpWB8/IC+O+ZTCO+kqrGk02zHgGLU36LlB+HEWZgUB1JXYaeiGgSY2jEy TXeQgqvBDbd3FWHxf7HtWeX3FStOYnN2ctIr+bgLi+B4rnhYHflJdiPgAH40B8sr zENTg7U6B65OBKVqXi3DbboEg8WZx/TrcM22YpVjyccTsjHk1YvcoCCimVaH0LIW 4vxseBu4XlZfnXvu24+8fR6uVy51ZTDjvzEQPhsX/T0d5i3SW061vOTduo0DWcJn oVgtRrMJ4MkYl3NqPx5cViplfpKmr3GTH8PrGTKTWVQMMBCtNLaJ0ZhiP4UofRfY Jb44pMMciW4h4QW7aG2FQEm3BOED2+/a5Cv7XQpubwGdF6E/653RgS4J+CX5H9rf pkrbyn7GaH7qRNlr4AIM+YdLgTxOl2LM+9P52rJRxLbzvkDtzz/AS7J2WPPgVHAz C4CYoghbazxk1BtxVgLPobttqFWo5x+4nPF3WuzqztHDJLjlucULfkLWXm0ScpxI qVv4xmtxcK9e44hUAdaIxE8dTxDYcWSItKky42wJS2KGIP76exuambd/OC5aSeCf j7JZ+UHsbhxnf+WaY1jdQ3iXm9W9c615HdV58xTemrQZVGB4EpHG8fEpvZEY7uLD 9JnaSrxNu3oZHq73nrQN =2mm/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Mod_jk Configuration
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chris,
On 1/21/15 6:41 PM, Chris Arnold wrote:
Chris,
On 1/21/15 5:56 PM, Chris wrote: You must have changed something
since your original configuration. Do you have JkMount ajp13
somewhere? You need to use the worker name and not the protocol
name.
Can you post your updated workers.properties file, and related
httpd.conf configurations?
workers.properties:
worker.list=jk-status worker.jk-status.type=status
worker.jk-status.read_only=true worker.list=jk-manager
worker.list=worker1 worker.jk-manager.type=status
You have two status workers. Is that intentional?
worker.list=balancer worker.balancer.type=lb
worker.balancer.max_reply_timeouts=10
worker.balancer.balance_workers=worker1
worker.worker1.reference=worker.template
worker.worker1.host=localhost worker.worker1.port=8009
worker.worker1.activation=A worker.template.type=ajp13
worker.template.socket_keepalive=true version of mod_jk running
1.2.26
If you are really running 1.2.26, you should upgrade to 1.2.40.
worker.template.connection_pool_minsize=0
That's an odd setting. Do you expect long periods of time during which
no requests will be handled?
worker.template.connection_pool_timeout=600
worker.template.reply_timeout=30
worker.template.recovery_options=3
Httpd.conf:
Include /opt/alfresco/tomcat/conf/jk.conf
apache vhost:
IfDefine SSL IfDefine !NOSSL
## ## SSL Virtual Host Context ##
VirtualHost 192.168.123.200:443
# General setup for the virtual host DocumentRoot
/opt/alfresco/tomcat/webapps/share ServerName
share2.domain.tld:443 ServerAlias mail.* ifolder.* share.* apps.*
ErrorLog /var/log/apache2/ssl-error_log TransferLog
/var/log/apache2/ssl-access_log LogLevel Debug LogLevel
rewrite:trace8
# SSL Engine Switch: # Enable/Disable SSL for this virtual
host. SSLEngine on
#This rewrites https://share.anydomain.tld to our share server
#RewriteEngine On #RewriteCond %{HTTP_HOST} ^share2\. #RewriteCond
%{HTTPS} on #RewriteCond %{REQUEST_URI} !^/share2/ #RewriteRule
^/(.*) https://share2.teknerds.net:8443/share/ [P] JkMount
/share2/* worker1
Found it! IT was in the jk.conf file: JkMount /share2/*.* ajp13 I
have removed ajp13 so now that line looks like: JkMount
/share2/*.*
*.* won't do what you want it to do. Please check out the Apache httpd
guide here for the syntax for JkMount:
http://tomcat.apache.org/connectors-doc/reference/apache.html
Restart apache and got this error: Jan 21 18:38:02 labweb
start_apache2[3042]: AH00526: Syntax error on line 32 of
/opt/alfresco/tomcat/conf/jk Jan 21 18:38:02 labweb
start_apache2[3042]: JkMount needs a path when not defined in a
location
So i commented it out (it was like this originally).
So then you don't have any JkMounts, so nothing will be proxied.
What you want is:
JkMount /share2/* worker1
or maybe:
JkMount /share2/* balancer
workers.properties defines the workers (target host/port, connection
options, etc.) and the JkMount directives in httpd.conf map URL
patterns to those workers.
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJUwQucAAoJEBzwKT+lPKRY2NQQAKb9tQ2MvvqCzus6/jtghFCy
qIsjB9qYpY9tdM1S9ml2SHVvmbfBmT7eZysgpCHjQOIqw5+bIxee6lxOrPcRNEFy
RN6H8NFDtBkDiKF4zLx0UpDYICHwGD0VcvXG4FXMR1505zcYOcmzZOOEoAbsNiJX
YESTjShLlRPe+vABBQ3NFTuFwsH0auDUveFsYREAnsYgaYIfbf607ydajwiJy8HN
czS4nwWhb3nFhQcVgeZCMyO1sHaXB+jmb5EGbWogsoRjB7Nr7mf7KhTVzJiq6SFZ
sYcji3rscEnZ5h0MNHxuMhYlz2lsOUFhEzn5nxQAFPn8XtUY/BsO5SEHypXJKJL2
qNP57uops6u11QvLVtf14SUUDeVAJcL/AFgn+h6MHVpfThqwbjmARKP+q4kZNdmY
c0FTyelDq6fLZ68h/cUi6hB6hBiV34JgJZQXMhTFcYmIcK0HVjmdXrIPnNMXlNfk
uszxqDSmElaJo9RrJXzBMFxxSZGmpmYkUctlvdZCOPzZi46k2PW8G49geiH2PYRa
NTdmpW6b9HawWWdgZ7Pw2tVEeeiEDe+eFaMecDRsT6bbkMtikkbLFn7uQTp6lavL
eY0I1TLCt1r+uqJGvKNw5lPRjIYuLl8XDZ7nFZPL7sEJjK1heVfaDayIpF9eTD6d
fxgIG01ai16qg7NzSIEf
=gV4t
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
br /
User Principal: %= request.getUserPrincipal() % br/
%
if (request.getUserPrincipal() != null ) {
%
User is authenticated, allow to set session attribute
%
request.getSession().setAttribute(markerAttribute, markerAttributeValue);
}
else {
%
User is a guest. No setting of any session attributes.
%
}
%
br /
Marker Attribute from session: %=
request.getSession().getAttribute(markerAttribute) %
On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
I think I could reproduce my problem also on experimenting with your examples!
I went exactly by your steps but my JSP is an extended version of
yours ( I add it to attachment )
In the ROOT/test.jsp I added code to set a session attribute if the
user principal is not null.
I expect that after logging out via another application (using SSO) my
session attribute won't be there (my expectation of SingleSignOff is
complete session invalidation).
However it's not the case : after logging out in security/protected
the session attribute is still kept (while UserPrincipal is null).
Complete scenario:
- request ROOT/test.jsp
- no authenticated user
- no marker attribute in session
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- marker attribute is shown from session.
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
However - the marker attribute is STILL in session of ROOT webapplication.
For us it means that the session is NOT invalidated correctly.
Thanks for your feedback and detail scenario you sent, I think it
helped discover a probable bug...
On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
Hello!
I tried 8.0.17 (previously I had 8.0.15) and we still have the same
problem with same possible workaround.
I'll go through your examples, try them and compare what's the difference.
On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote:
On 20/01/2015 08:10, Leonid Rozenblyum wrote:
Thank you, Mark!
I spent some time stepping through the code using a default Tomcat
install with the following changes:
- SSO Valve uncommented in server.xml
- test.jsp added to ROOT app that shows request.getUserPrincipal
- uncomment user definitions in tomcat-users.xml
Note that the examples app ships with a protected page that requires
authentication.
I see the following:
- request ROOT/test.jsp
- no authenticated user
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
So, in short, I am seeing the behaviour you expect to see. I'm doing
this with 9.0.x (trunk) but that should be the same as the latest 80.x
release.
A couple of things to check:
- are you using the latest 8.0.x release (8.0.17 - I need to send out
the announcement)
- Turn on debug logging for the Host where you added the SSO valve - you
should see debug messages from the SSO valve which will show when
sessions get created, destroyed etc.
Mark
On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas ma...@apache.org wrote:
On 16/01/2015 14:05, Leonid Rozenblyum wrote:
Hello Mark.
We do explicit forced expiration of http session in one of SSO enabled
apps (Application1 : session.invalidate() )
and it didn't cause session expiration in other Apps
(only workaround with adding security-constraint to other apps that I
mentioned above helped).
Tomcat version is 8.0.15. OS tested was both linux windows
Probably I need to prepare minimal test case since it looks like a bug,
right?
Yes to the possible bug. Thanks but no need at this point for the test
case. I'll take a look at what is going on.
Mark
On Fri, Jan 16, 2015 at 2:53 PM, Mark Thomas ma...@apache.org wrote:
On 15/01/2015 15:46, Leonid Rozenblyum wrote:
Hello.
I have 2 web-applications which are running on the same host.
The Valve SingleSignOn is enabled.
Application1 has security-constraint and login-config elements in
web.xml
Application2, 3 etc has no such definitions
Technically Application1 is acting as a security gate. All
Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
I think I could reproduce my problem also on experimenting with your examples! I went exactly by your steps but my JSP is an extended version of yours ( I add it to attachment ) In the ROOT/test.jsp I added code to set a session attribute if the user principal is not null. I expect that after logging out via another application (using SSO) my session attribute won't be there (my expectation of SingleSignOff is complete session invalidation). However it's not the case : after logging out in security/protected the session attribute is still kept (while UserPrincipal is null). Complete scenario: - request ROOT/test.jsp - no authenticated user - no marker attribute in session - request examples/jsp/security/protected - FORM login prompt, login, see index.jsp - request ROOT/test.jsp - shows user authenticated above. SSO cookie has a path of / so gets returned with all requests. This exposes the UserPrincipal to all apps - marker attribute is shown from session. - request examples/jsp/security/protected - see index.jsp - click logout - see FORM login page - request ROOT/test.jsp - no authenticated user. As expected. Logout above has destroyed SSO session and removed SSO cookie However - the marker attribute is STILL in session of ROOT webapplication. For us it means that the session is NOT invalidated correctly. Thanks for your feedback and detail scenario you sent, I think it helped discover a probable bug... On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum lrozenbl...@gmail.com wrote: Hello! I tried 8.0.17 (previously I had 8.0.15) and we still have the same problem with same possible workaround. I'll go through your examples, try them and compare what's the difference. On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote: On 20/01/2015 08:10, Leonid Rozenblyum wrote: Thank you, Mark! I spent some time stepping through the code using a default Tomcat install with the following changes: - SSO Valve uncommented in server.xml - test.jsp added to ROOT app that shows request.getUserPrincipal - uncomment user definitions in tomcat-users.xml Note that the examples app ships with a protected page that requires authentication. I see the following: - request ROOT/test.jsp - no authenticated user - request examples/jsp/security/protected - FORM login prompt, login, see index.jsp - request ROOT/test.jsp - shows user authenticated above. SSO cookie has a path of / so gets returned with all requests. This exposes the UserPrincipal to all apps - request examples/jsp/security/protected - see index.jsp - click logout - see FORM login page - request ROOT/test.jsp - no authenticated user. As expected. Logout above has destroyed SSO session and removed SSO cookie So, in short, I am seeing the behaviour you expect to see. I'm doing this with 9.0.x (trunk) but that should be the same as the latest 80.x release. A couple of things to check: - are you using the latest 8.0.x release (8.0.17 - I need to send out the announcement) - Turn on debug logging for the Host where you added the SSO valve - you should see debug messages from the SSO valve which will show when sessions get created, destroyed etc. Mark On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas ma...@apache.org wrote: On 16/01/2015 14:05, Leonid Rozenblyum wrote: Hello Mark. We do explicit forced expiration of http session in one of SSO enabled apps (Application1 : session.invalidate() ) and it didn't cause session expiration in other Apps (only workaround with adding security-constraint to other apps that I mentioned above helped). Tomcat version is 8.0.15. OS tested was both linux windows Probably I need to prepare minimal test case since it looks like a bug, right? Yes to the possible bug. Thanks but no need at this point for the test case. I'll take a look at what is going on. Mark On Fri, Jan 16, 2015 at 2:53 PM, Mark Thomas ma...@apache.org wrote: On 15/01/2015 15:46, Leonid Rozenblyum wrote: Hello. I have 2 web-applications which are running on the same host. The Valve SingleSignOn is enabled. Application1 has security-constraint and login-config elements in web.xml Application2, 3 etc has no such definitions Technically Application1 is acting as a security gate. All other applications are redirected to it if userPrincipal is not found. In this scenario Single Sign ON works fine - after authenticating in Application1, all other applications have correction userPrincipal. However Single Sign OFF doesn't work in this configuration. If I logout in App1, other sessions are not invalidated. How can this be overcomed? Is it a bug or works-as-intended? Explicit, forced expiration of the HTTP session in any SSO enabled web application should destroy the SSO session and in turn trigger the expiration of the HTTP session for every other SSO enabled web application. Session
Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Terry, On 1/21/15 5:33 PM, Terry Medearis wrote: Greetings,I have inherited code that calls: org.apache.catalina.startup.Catalina.process(args). So... embedded? I now need to upgrade this code to Tomcat 8. Currently, we are using Tomcat 6. I have previously upgraded with no problems, but both Tomcat 7 and 8 do not have the .process method. I can not find any documentation as to what should be used in place of .process(args). I have tried: - Catalina.load(args) - Catalina.start() For both, the application failed with an error stating that the server could not be contacted. I'm sorry that I can not give more detail than that. I am counting on the idea that there must be some replacement for the .process() method that I am just not comprehending. If you know the replacement for org.apache.catalina.startup.Catalina.process(args) and could share it with me, I would be very grateful. You probably want to take a look at the Tomcat class, which has unified ans simplified a lot of the embedded setup for Tomcat. Many of the unit tests use the Tomcat class to construct and launch servers programatically, and so there are a wealth of examples available. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwRFIAAoJEBzwKT+lPKRY7xcP/RAcGeYA8GUBj+Arsija971V OthIf7SZpWB8/IC+O+ZTCO+kqrGk02zHgGLU36LlB+HEWZgUB1JXYaeiGgSY2jEy TXeQgqvBDbd3FWHxf7HtWeX3FStOYnN2ctIr+bgLi+B4rnhYHflJdiPgAH40B8sr zENTg7U6B65OBKVqXi3DbboEg8WZx/TrcM22YpVjyccTsjHk1YvcoCCimVaH0LIW 4vxseBu4XlZfnXvu24+8fR6uVy51ZTDjvzEQPhsX/T0d5i3SW061vOTduo0DWcJn oVgtRrMJ4MkYl3NqPx5cViplfpKmr3GTH8PrGTKTWVQMMBCtNLaJ0ZhiP4UofRfY Jb44pMMciW4h4QW7aG2FQEm3BOED2+/a5Cv7XQpubwGdF6E/653RgS4J+CX5H9rf pkrbyn7GaH7qRNlr4AIM+YdLgTxOl2LM+9P52rJRxLbzvkDtzz/AS7J2WPPgVHAz C4CYoghbazxk1BtxVgLPobttqFWo5x+4nPF3WuzqztHDJLjlucULfkLWXm0ScpxI qVv4xmtxcK9e44hUAdaIxE8dTxDYcWSItKky42wJS2KGIP76exuambd/OC5aSeCf j7JZ+UHsbhxnf+WaY1jdQ3iXm9W9c615HdV58xTemrQZVGB4EpHG8fEpvZEY7uLD 9JnaSrxNu3oZHq73nrQN =2mm/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSL issue in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ason, On 1/22/15 1:26 AM, Jason Y wrote: What I changed in server.xml is adding sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1. If you want to be able to handle SSL handshakes (and not just TLS ones like some older clients might require), you'll need to enable SSLv2hello along with all the TLS versions you have specified above. BUT I noticed that I am using JSSE instead of APR, so I remoeved the listener Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / is this causing my error? No. Using the AprLifecycleListener won't hurt anything; you'll just get a warning on startup that the native library isn't available. I'm not quite convinced this is an SSL problem, since most clients can handle a TLS handshake these days. Back to the original problem: how long does your application work before it doesn't. When it doesn't work, what happens when you try to connect? Long timeout? Immediate connection refusal? Failed handshake? You need to provide more information. Can you summarize the problem again and give specifics? - -chris On Wed, Jan 21, 2015 at 11:39 PM, Jason Y day...@gmail.com wrote: You mean here maxThreads=150? But is no respective log message for this. And, I didn't find much request to the service. Currently there are no changed settings(firewall/network, etc.). On Wed, Jan 21, 2015 at 11:28 PM, Jeffrey Janner jeffrey.jan...@polydyne.com wrote: -Original Message- From: Jason Y [mailto:day...@gmail.com] Sent: Wednesday, January 21, 2015 12:44 AM To: Tomcat Users List Subject: Re: SSL issue in tomcat Got another issue...Tomcat is working fine after restart but it cannot last long. Now I cannot access https pages with any browsers. I didn't find anything useful in logs. After a restart, it works well again. Connector executor=tomcatThreadPool port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= / !-- Define an AJP 1.3 Connector on port 8009 -- Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / Just a thought, but since it works for a while and then stops responding, could it be that the OP is running out of processing threads, i.e. a thread or connection pool leak? On Wed, Jan 21, 2015 at 10:01 AM, Sanaullah sanaulla...@gmail.com wrote: its not necessary to have ciphers properties but if you want to restrict the ciphers then you can use this property. On Wed, Jan 21, 2015 at 6:53 AM, Jason Y day...@gmail.com wrote: Thank you all. Now it is working fine. Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslProtocol=TLS sslEnabledProtocols=TLSv1.2,TLSv1.1,TLSv1 keystoreFile=lib/cert/.keystore keystorePass= ciphers=TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA / By the way, do I need ciphers properties here? On Tue, Jan 20, 2015 at 11:22 PM, Christopher Schultz ch...@christopherschultz.net wrote: Jason, On 1/20/15 4:17 AM, Jason Y wrote: Recently my application cannot be accessible in browser with https version. I think it is due to vulnerability in ssl 3.0 issue. I checked my tomcat configuration and replaced sslProtocol=TLS with sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 to disable SSL 3.0. Connector port=8080 protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 protocol=org.apache.coyote.http11.Http11Protocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 keystoreFile=xxx keystorePass=xxx / Connector port=8009 protocol=AJP/1.3 redirectPort=8443 / None of the responses you have gotten thus far are useful in any way. Your configuration looks fine to me: sslEnabledProtocols is the way to go, although in recent versions of Tomcat the default is NOT to include any SSL protocols and only use the TLS ones, so if you are running something recent, you should be okay. Then I can open my application https link in browser. BUT, good time never lasts too long, after several hours, I failed to access my https link again. What kinds of errors do you get? What do the logs say? What are the URLs you are using? Anyone has any ideas about this? please share your suggestions...My tomcat version is 7.0.55 Those SSL/TLS defaults I mentioned above were done in 7.0.57, so you should definitely keep your above configuration. There is no need to add a trust store or cipher specification to that. -chris
Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8
Chris, Another question... So, I understand that the Tomat class has been introduced, but is there anything in the Catalina class that remains that can be utilized in place of the .process method? Thanks, Terry From: Terry Medearis tmedearis80...@yahoo.com.INVALID To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 22, 2015 8:54 AM Subject: Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8 Chris, Embedded? Yes, I guess that it is. I'm sorry, I've worked with Tomcat in the past, but not much with this application, and I do not understand much about the architecture of this aspect of the application that I have inherited. I will check the Tomcat class and look for the unit tests to which you refer. Thank you very much. Terry From: Christopher Schultz ch...@christopherschultz.net To: Tomcat Users List users@tomcat.apache.org Sent: Thursday, January 22, 2015 8:03 AM Subject: Re: org.apache.catalina.startup.Catalina.process(args)... method in Tomcat 6 but not 7 nor 8 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Terry, On 1/21/15 5:33 PM, Terry Medearis wrote: Greetings,I have inherited code that calls: org.apache.catalina.startup.Catalina.process(args). So... embedded? I now need to upgrade this code to Tomcat 8. Currently, we are using Tomcat 6. I have previously upgraded with no problems, but both Tomcat 7 and 8 do not have the .process method. I can not find any documentation as to what should be used in place of .process(args). I have tried: - Catalina.load(args) - Catalina.start() For both, the application failed with an error stating that the server could not be contacted. I'm sorry that I can not give more detail than that. I am counting on the idea that there must be some replacement for the .process() method that I am just not comprehending. If you know the replacement for org.apache.catalina.startup.Catalina.process(args) and could share it with me, I would be very grateful. You probably want to take a look at the Tomcat class, which has unified ans simplified a lot of the embedded setup for Tomcat. Many of the unit tests use the Tomcat class to construct and launch servers programatically, and so there are a wealth of examples available. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUwRFIAAoJEBzwKT+lPKRY7xcP/RAcGeYA8GUBj+Arsija971V OthIf7SZpWB8/IC+O+ZTCO+kqrGk02zHgGLU36LlB+HEWZgUB1JXYaeiGgSY2jEy TXeQgqvBDbd3FWHxf7HtWeX3FStOYnN2ctIr+bgLi+B4rnhYHflJdiPgAH40B8sr zENTg7U6B65OBKVqXi3DbboEg8WZx/TrcM22YpVjyccTsjHk1YvcoCCimVaH0LIW 4vxseBu4XlZfnXvu24+8fR6uVy51ZTDjvzEQPhsX/T0d5i3SW061vOTduo0DWcJn oVgtRrMJ4MkYl3NqPx5cViplfpKmr3GTH8PrGTKTWVQMMBCtNLaJ0ZhiP4UofRfY Jb44pMMciW4h4QW7aG2FQEm3BOED2+/a5Cv7XQpubwGdF6E/653RgS4J+CX5H9rf pkrbyn7GaH7qRNlr4AIM+YdLgTxOl2LM+9P52rJRxLbzvkDtzz/AS7J2WPPgVHAz C4CYoghbazxk1BtxVgLPobttqFWo5x+4nPF3WuzqztHDJLjlucULfkLWXm0ScpxI qVv4xmtxcK9e44hUAdaIxE8dTxDYcWSItKky42wJS2KGIP76exuambd/OC5aSeCf j7JZ+UHsbhxnf+WaY1jdQ3iXm9W9c615HdV58xTemrQZVGB4EpHG8fEpvZEY7uLD 9JnaSrxNu3oZHq73nrQN =2mm/ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
Hello Mark!
I'll investigate deeper the SingleSignOn class to understand how to
extend it to allow adding the session always.
To summarize : my understanding of current behaviour is following:
- if a web application uses authentication (has security-constraint?)
- then SingleSignOn will provide :
a) correct request.getUserPrincipal()
b) correct session invalidation
- if a web application is not using authentication - SingleSignOn
will just provide
a) correct request.getUserPrincipal()
Probably there were some logical architectural backgrounds to take
this decision
But for us it was counter-intuitive. We expected either a)+b) are both
available or nothing.
Presence of just a) caused unexpected security issues in our app when
after logout and logging in with lower permissions user had access to
data stored for high-privileged user.
Thanks for your help!
On Thu, Jan 22, 2015 at 7:12 PM, Mark Thomas ma...@apache.org wrote:
On 22/01/2015 16:25, Leonid Rozenblyum wrote:
So doesn't As soon as the user logs out of one web application (for
example, by invalidating the corresponding session if form based login
is used), the user's sessions in all web applications will be
invalidated. ( this phrase is from official doc) imply that all
sessions are invalidated and thus attributes are cleared?
(and as I mentioned above : there is some workaround that looks like
forces Tomcat to work exactly like this).
A session is only added to SSO if the web application uses
authentication. You could extend the SSOValve to always add the session
if you wish.
Mark
On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas ma...@apache.org wrote:
On 22/01/2015 16:12, Leonid Rozenblyum wrote:
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
br /
User Principal: %= request.getUserPrincipal() % br/
%
if (request.getUserPrincipal() != null ) {
%
User is authenticated, allow to set session attribute
%
request.getSession().setAttribute(markerAttribute,
markerAttributeValue);
}
else {
%
User is a guest. No setting of any session attributes.
%
}
%
You need to remove the session attribute if the user is not authentication.
Tomcat's SSO is working as expected. You are, of course, free to
extend/patch it if you prefer.
Mark
br /
Marker Attribute from session: %=
request.getSession().getAttribute(markerAttribute) %
On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
I think I could reproduce my problem also on experimenting with your
examples!
I went exactly by your steps but my JSP is an extended version of
yours ( I add it to attachment )
In the ROOT/test.jsp I added code to set a session attribute if the
user principal is not null.
I expect that after logging out via another application (using SSO) my
session attribute won't be there (my expectation of SingleSignOff is
complete session invalidation).
However it's not the case : after logging out in security/protected
the session attribute is still kept (while UserPrincipal is null).
Complete scenario:
- request ROOT/test.jsp
- no authenticated user
- no marker attribute in session
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- marker attribute is shown from session.
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
However - the marker attribute is STILL in session of ROOT webapplication.
For us it means that the session is NOT invalidated correctly.
Thanks for your feedback and detail scenario you sent, I think it
helped discover a probable bug...
On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
Hello!
I tried 8.0.17 (previously I had 8.0.15) and we still have the same
problem with same possible workaround.
I'll go through your examples, try them and compare what's the
difference.
On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote:
On 20/01/2015 08:10, Leonid Rozenblyum wrote:
Thank you, Mark!
I spent some time stepping through the code using a default Tomcat
install with the following changes:
- SSO Valve uncommented in server.xml
- test.jsp added to ROOT app that shows request.getUserPrincipal
- uncomment user definitions in tomcat-users.xml
Note that the examples app ships with a protected page that requires
authentication.
I see the following:
- request ROOT/test.jsp
- no authenticated user
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user
Re: [ Tomcat8 ] [ SingleSignOn ] 2 Webapplications
On 22/01/2015 16:25, Leonid Rozenblyum wrote:
So doesn't As soon as the user logs out of one web application (for
example, by invalidating the corresponding session if form based login
is used), the user's sessions in all web applications will be
invalidated. ( this phrase is from official doc) imply that all
sessions are invalidated and thus attributes are cleared?
(and as I mentioned above : there is some workaround that looks like
forces Tomcat to work exactly like this).
A session is only added to SSO if the web application uses
authentication. You could extend the SSOValve to always add the session
if you wish.
Mark
On Thu, Jan 22, 2015 at 6:21 PM, Mark Thomas ma...@apache.org wrote:
On 22/01/2015 16:12, Leonid Rozenblyum wrote:
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
br /
User Principal: %= request.getUserPrincipal() % br/
%
if (request.getUserPrincipal() != null ) {
%
User is authenticated, allow to set session attribute
%
request.getSession().setAttribute(markerAttribute,
markerAttributeValue);
}
else {
%
User is a guest. No setting of any session attributes.
%
}
%
You need to remove the session attribute if the user is not authentication.
Tomcat's SSO is working as expected. You are, of course, free to
extend/patch it if you prefer.
Mark
br /
Marker Attribute from session: %=
request.getSession().getAttribute(markerAttribute) %
On Thu, Jan 22, 2015 at 5:51 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
I think I could reproduce my problem also on experimenting with your
examples!
I went exactly by your steps but my JSP is an extended version of
yours ( I add it to attachment )
In the ROOT/test.jsp I added code to set a session attribute if the
user principal is not null.
I expect that after logging out via another application (using SSO) my
session attribute won't be there (my expectation of SingleSignOff is
complete session invalidation).
However it's not the case : after logging out in security/protected
the session attribute is still kept (while UserPrincipal is null).
Complete scenario:
- request ROOT/test.jsp
- no authenticated user
- no marker attribute in session
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- marker attribute is shown from session.
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
However - the marker attribute is STILL in session of ROOT webapplication.
For us it means that the session is NOT invalidated correctly.
Thanks for your feedback and detail scenario you sent, I think it
helped discover a probable bug...
On Wed, Jan 21, 2015 at 7:06 PM, Leonid Rozenblyum
lrozenbl...@gmail.com wrote:
Hello!
I tried 8.0.17 (previously I had 8.0.15) and we still have the same
problem with same possible workaround.
I'll go through your examples, try them and compare what's the difference.
On Tue, Jan 20, 2015 at 11:52 AM, Mark Thomas ma...@apache.org wrote:
On 20/01/2015 08:10, Leonid Rozenblyum wrote:
Thank you, Mark!
I spent some time stepping through the code using a default Tomcat
install with the following changes:
- SSO Valve uncommented in server.xml
- test.jsp added to ROOT app that shows request.getUserPrincipal
- uncomment user definitions in tomcat-users.xml
Note that the examples app ships with a protected page that requires
authentication.
I see the following:
- request ROOT/test.jsp
- no authenticated user
- request examples/jsp/security/protected
- FORM login prompt, login, see index.jsp
- request ROOT/test.jsp
- shows user authenticated above. SSO cookie has a path of / so gets
returned with all requests. This exposes the UserPrincipal to all
apps
- request examples/jsp/security/protected
- see index.jsp
- click logout
- see FORM login page
- request ROOT/test.jsp
- no authenticated user. As expected. Logout above has destroyed SSO
session and removed SSO cookie
So, in short, I am seeing the behaviour you expect to see. I'm doing
this with 9.0.x (trunk) but that should be the same as the latest 80.x
release.
A couple of things to check:
- are you using the latest 8.0.x release (8.0.17 - I need to send out
the announcement)
- Turn on debug logging for the Host where you added the SSO valve - you
should see debug messages from the SSO valve which will show when
sessions get created, destroyed etc.
Mark
On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas ma...@apache.org wrote:
On 16/01/2015 14:05, Leonid Rozenblyum
RE: Tomcat 8 encoding issues: unable to change the default encoding iso-8859-1 to utf-8 in http header
Hi all, Found the issue it's the jsp page itself that was encoded in iso-8859-1 format. Sighs .. I became such a noob. Sorry all for the trouble. With regards Prabhu -Original Message- From: Prabhu Mannu [mailto:pra...@fernridge.com] Sent: Friday, 23 January, 2015 3:21 PM To: users@tomcat.apache.org Subject: Tomcat 8 encoding issues: unable to change the default encoding iso-8859-1 to utf-8 in http header Hi all, Firs off Sorry if this question appears too noob. Currently in my application I get this warning. HTML1114: Codepage iso-8859-1 from (HTTP header) overrides conflicting codepage utf-8 from (META tag) File: index.action Application uses struts 2, spring, hibernate, jpa + tiles 3 framework. The application does have this meta tag in all the jsp files meta charset=utf-8 Tomcat version 8 is used Server version:Apache Tomcat/8.0.15 JVM Version: 1.7.0_51-b13 JVM Vendor:Oracle Corporation Also have as java parameters -Dfile.encoding=UTF-8 and -Djavax.servlet.request.encoding=UTF-8 In server.xml Connector connectionTimeout=2 port=8089 protocol=HTTP/1.1 redirectPort=8443 URIEncoding=UTF-8 useBodyEncodingForURI=true / In web.xml in conf folder filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter -class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param async-supportedtrue/async-supported /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping In web.xml of the application jsp-config jsp-property-group url-pattern*.jsp/url-pattern page-encodingUTF-8/page-encoding trim-directive-whitespacestrue/trim-directive-whitespaces /jsp-property-group /jsp-config filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter -class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping But I still get this warning Codepage iso-8859-1 from (HTTP header) overrides conflicting codepage utf-8 from (META tag) I tried to move/change the order of the filters for setting encoding but doesn't seem to make any difference. I cannot figure out what is wrong and why the http header is saying iso-8859-1 encoding instead of utf-8. I need utf-8 cause this application need to support Japanese language. I welcome anyone to give me any suggestion/comments/or pointers on what I am doing wrong. With regards Prabhu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 encoding issues: unable to change the default encoding iso-8859-1 to utf-8 in http header
Hi all, Firs off Sorry if this question appears too noob. Currently in my application I get this warning. HTML1114: Codepage iso-8859-1 from (HTTP header) overrides conflicting codepage utf-8 from (META tag) File: index.action Application uses struts 2, spring, hibernate, jpa + tiles 3 framework. The application does have this meta tag in all the jsp files meta charset=utf-8 Tomcat version 8 is used Server version:Apache Tomcat/8.0.15 JVM Version: 1.7.0_51-b13 JVM Vendor:Oracle Corporation Also have as java parameters -Dfile.encoding=UTF-8 and -Djavax.servlet.request.encoding=UTF-8 In server.xml Connector connectionTimeout=2 port=8089 protocol=HTTP/1.1 redirectPort=8443 URIEncoding=UTF-8 useBodyEncodingForURI=true / In web.xml in conf folder filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter -class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param async-supportedtrue/async-supported /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping In web.xml of the application jsp-config jsp-property-group url-pattern*.jsp/url-pattern page-encodingUTF-8/page-encoding trim-directive-whitespacestrue/trim-directive-whitespaces /jsp-property-group /jsp-config filter filter-namesetCharacterEncodingFilter/filter-name filter-classorg.apache.catalina.filters.SetCharacterEncodingFilter/filter -class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-namesetCharacterEncodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping But I still get this warning Codepage iso-8859-1 from (HTTP header) overrides conflicting codepage utf-8 from (META tag) I tried to move/change the order of the filters for setting encoding but doesn't seem to make any difference. I cannot figure out what is wrong and why the http header is saying iso-8859-1 encoding instead of utf-8. I need utf-8 cause this application need to support Japanese language. I welcome anyone to give me any suggestion/comments/or pointers on what I am doing wrong. With regards Prabhu - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
