On 14/10/11 04:04, Brian Burch wrote:
I will go quiet for a few days while I checkout 6.0.28 and get it to
build.
Phew! That took me longer than I expected I got 6.0.28 to build,
then ran all the unit tests, then debugged the SSO logic and started to
understand it.
Then I (coded/debugge
On 13/10/11 15:14, Brian Burch wrote:
On 13/10/11 11:39, Brian Burch wrote:
To summarise: the webapp's explicit timeout is not being honoured
because its web.xml does not define a section. Therefore,
the webapp has defaulted to use the NonLoginAuthenticator - which
honours the existing SSO stat
On 13/10/11 15:14, Brian Burch wrote:
I beleve the division of responsibilities between the AuthenticatorBase
abstract class and its extension classes is wrong. At the moment, it is
the responsibility of the concrete class authenticate methods to add the
Session to the existing SingleSignOnEntry
On 13/10/11 11:39, Brian Burch wrote:
To summarise: the webapp's explicit timeout is not being honoured
because its web.xml does not define a section. Therefore,
the webapp has defaulted to use the NonLoginAuthenticator - which
honours the existing SSO state (via the client cookie), but does not
On 13/10/11 05:29, Konstantin Kolinko wrote:
What happens when an non-authenticated user accesses one of those webapps?
It just rejects it with 403, or it should display a login form (and
authenticate him/her and create a SSO cookie), or redirect to another
webapp that has a login form?
Sorry,
2011/10/12 Brian Burch :
>
> OK, it now all makes some kind of sense. I've discovered that the Session
> associated with the second webapp is never being associated with the SSO
> instance created by the first webapp. However, the weird thing is that the
> protected resources of the second webapp a
On 12/10/11 12:35, Brian Burch wrote:
I've successfully run a remote debugger session against the SingleSignOn
Valve while it is handling my timeout scenario.
Interestingly, the logic to handle the timeout of a single webapp is
exactly as I wanted it to be... only the specific Session is removed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 10/12/2011 8:53 AM, Brian Burch wrote:
> My tomcat 6.0.28 compiled class for AuthenticatorBase does not
> match the 6.0.33 source code I am debugging with. The SSO Valve is
> pretty much the same.
So get the source for 6.0.28:
http://archi
On 12/10/11 12:51, Konstantin Kolinko wrote:
Something becomes clearer.
Remembering the session as associated with ssoid is performed by
SingleSignOn.associate(..) method. This method is called by
AuthenticatorBase class.
Those webapps with long living sessions - are they protected by
security
2011/10/12 Brian Burch :
>
> I've successfully run a remote debugger session against the SingleSignOn
> Valve while it is handling my timeout scenario.
>
> Interestingly, the logic to handle the timeout of a single webapp is exactly
> as I wanted it to be... only the specific Session is removed fro
On 11/10/11 22:24, Christopher Schultz wrote:
I'm not an expert at SSO, nor have I ever used it on any of my
projects. All my answers should be considered suspicious :)
>
So, it looks like the Valve should *not* be expiring your SSO when the
"static" webapp's session expires. Can you confirm th
On 11/10/11 22:24, Christopher Schultz wrote:
Super thoughts, Chris, but thanks also to everyone else who has
commented. I really appreciate everyone's contributions because (until
now) I felt I was "out there" on my own, ignorant and stupid. It is
reassuring to find that my analysis is not wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 10/11/2011 12:35 PM, Brian Burch wrote:
> OK, I think I understand the distinction you are making, which is
> consistent with there being a Session array (rather than a simple
> field) in the SingleSignOnEntry class.
I haven't looked at th
2011/10/11 Brian Burch :
>
> 2. My root welcome page does an html redirect to a small webapp called
> static, which has its own web.xml. The redirect is to a page which is
> protected by a security contraint which requires a FORM-based login (this
> server only has an SSL Connector defined). The st
Brian Burch wrote:
...
But I am having trouble understanding the life cycle of a Session. If
the browser has navigated away from my "static" webapp container, into a
completely different webapp container, why does it still have an
associated Session?
Probably because the first webapp has n
On 11/10/11 16:27, Christopher Schultz wrote:
Thanks very much for your speedy and informative reply, Christopher.
While my question is fresh in your mind, I hope you will not mind too
much if I ask a couple of relevant questions to clarify your answers below.
-BEGIN PGP SIGNED MESSAGE--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian,
On 10/11/2011 10:09 AM, Brian Burch wrote:
> 6. The user tries to refresh the second webapp's page after about
> 25 minutes, but the GET fails with 403 status and the explanation
> "access to resource has been denied". Apparently, the user's
>
I am using tomcat 6.0.28 (actually the 6.0.28-10ubuntu2 package) as a
standalone web server. I am getting timeout behaviour that sort-of makes
sense, but doesn't agree with the way I read the servlet spec.
I have associated the org.apache.catalina.authenticator.SingleSignOn
Valve with my Engin
18 matches
Mail list logo
