al Message-
From: Greg Wilkins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 9:20 AM
To: [EMAIL PROTECTED]
Subject: Re: Question about web app login, user principal, and
authentication
Jeppe Sommer (Trifork) wrote:
Greg,
I agree that there is an amount of implementati
t: Tuesday, January 10, 2006 9:20 AM
To: [EMAIL PROTECTED]
Subject: Re: Question about web app login, user principal, and
authentication
Jeppe Sommer (Trifork) wrote:
> Greg,
>
> I agree that there is an amount of implementation freedom wrt. when
> getUserPrincipal can be expec
Jeppe Sommer (Trifork) wrote:
> Greg,
>
> I agree that there is an amount of implementation freedom wrt. when
> getUserPrincipal can be expected to return non-null depending on the
> caching strategy of the container, at least when using basic login.
> However, with form based login (which, in my
I would tend to agree with Jeppe here.
Thanks,
Aaron
On 1/9/06, Jeppe Sommer (Trifork) <[EMAIL PROTECTED]> wrote:
> Greg,
>
> I agree that there is an amount of implementation freedom wrt. when
> getUserPrincipal can be expected to return non-null depending on the
> caching strategy of the co
Greg,
I agree that there is an amount of implementation freedom wrt. when
getUserPrincipal can be expected to return non-null depending on the
caching strategy of the container, at least when using basic login.
However, with form based login (which, in my experience, is by far the
most common
Jeppe Sommer wrote:
> I think that it is possible to read from the servlet spec that
> getUserPrincipal should return the current principal for an unprotected
> resource. Take the following quote (servlet 2.4, section 12.10):
Jeppe,
The problem is that "current" is just not defined and it is to
I think that it is possible to read from the servlet spec that
getUserPrincipal should return the current principal for an unprotected
resource. Take the following quote (servlet 2.4, section 12.10):
"Being logged in to a web application corresponds precisely to there
being a valid non-null va
My preferred behavior would be to return the login Principal of the
user even for unauthenticated pages (unless they've logged out or
timed out, of course). As a side effect, I think this would let us
drop the required defualt principal from the security mapping, which
would be great. Unfortunate
David,
I do not believe that the servlet spec well defines the behaviour of the
getUserPrincipal() method for un-secured resources.
I raised this with the EG during the 2.4 process and pointed out that
several containers implemented this differently. Specifically I wanted
to know that if getU
The servlet 2.4 spec, section 12.7 states:
"A security identity, or principal, must always be provided for use in a
call to an enterprise bean. The default mode in calls to enterprise
beans from web applications is for the security identity of a web user
to be propagated to the EJBTM container
i've been getting very confused by some behavior related to being
logged in and authentication while working with jetspeed, and I hope
someone can shed some light on what should be happening.
Lets suppose you have a web app with some secured resources and some
unsecured resources.
If you
11 matches
Mail list logo
