I wonder if it's possible in HttpSessionListener implementation get
access to actual Tomcat's StandardSession?
HttpSessionEvent contains reference to StandardSessionFacade.
Otherwise I cannot access Manager, Context etc which should led me to
SingleSignOn.
Should I go through dangerous reflection
Thanks for the great advice!
On Thu, Jan 29, 2015 at 12:57 PM, Mark Thomas wrote:
> On 29/01/2015 10:54, Leonid Rozenblyum wrote:
>> Hello! I'm trying to extend the SingleSignOn valve and if possible
>> could you point me how can I create a global session listener
>> without modifying configurati
On 29/01/2015 10:54, Leonid Rozenblyum wrote:
> Hello! I'm trying to extend the SingleSignOn valve and if possible
> could you point me how can I create a global session listener
> without modifying configurations of web applications?
>
> The idea is that I should catch all 'session create' events
Hello! I'm trying to extend the SingleSignOn valve and if possible
could you point me how can I create a global session listener
without modifying configurations of web applications?
The idea is that I should catch all 'session create' events from all
webapps, and if they have the 'custom SSO valv
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 provid
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 offici
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 th
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
>
> User Principal: <%= request.getUserPrincipal() %>
>
> <%
> if (request.getUserPrincipal() != null ) {
> %>
> User is authentica
Probably the attachment will be cut out by the mailing server.
So I send the text of the test.jsp here:
Hello
User Principal: <%= request.getUserPrincipal() %>
<%
if (request.getUserPrincipal() != null ) {
%>
User is authenticated, allow to set session attribute
<%
request.getSession().setAttri
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 log
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 wrote:
> On 20/01/2015 08:10, Leonid Rozenblyum wrote:
>> Tha
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 definition
Thank you, Mark!
On Tue, Jan 20, 2015 at 12:18 AM, Mark Thomas 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 expiratio
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
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
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
>
> Technica
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
applica
17 matches
Mail list logo