So I think I have it working and I didn't have to redirect the user,
which is good because that wasn't working anyway. I don't know if it
was JAAS or Struts, or what, but the login parameters were being
stripped from the request so they never got to the login page.
How I got it to work was th
Yea, but in this case, it may be something we need to live with.
The login page scriptlet code looks for the login credentials in the
request and sets the appropriate form fields as well as a flag we use to
indicate whether the form should be submitted immediately upon loading
and in either ca
Adam Gordon wrote:
I think the solution is
going to be to redirect the user to the default main page manually w/
the login parameters and JAAS should take over from there...hopefully.
Except a redirect must be to a GET, not a POST, and it would be
unfortunate to include the login credentials
Let me get this straight: All pages in your webapp are protected (not
available to non-logged in users), so when someone who is logged in on
the company's main site tries to get to a page in your webapp, JAAS
catches it and sends them to your webapp's login page, which might be
able to glean e
Adam Gordon wrote:
For background, we actually have two login pages: on is the login page
that is running inside our webapp that is running JAAS and POSTs to
j_security_check at form submission time. The other page is our
company's main website (Apache) and users can log in here too. What we
See my comments in my response to Laurie. We're basically using dual
login pages, one on our main website (Apache) and the other in our
webapp. I'm currently toying with the idea of a Filter to detect the
subsequent logins against an already authenticated session.
--adam
Dale Newfield wrote
I believe you are absolutely correct Laurie, because I've not yet seen a
way to get a handle to the LoginContext to call logout(). All we can do
is invalidate the session - which we do when the user logs out. This
removes the user principal from the request and indicates to JAAS that
the user
Laurie Harper wrote:
If you have a separate 'login' page (as opposed to having a login form
on each page) you might be able to get away with invalidating the
session when that page is shown, with the caveat that logged in users
would implicitly be logged out if they visit that page.
And in th
I don't think Container Managed Security has provisions for logging
users out, other than by expiring the session (and not even then if
you're relying on HTTP authentication rather than form-based).
If you have a separate 'login' page (as opposed to having a login form
on each page) you might
If you mean protecting the page w/ a security constraint, I think that
would be a problem in that JAAS would detect that it's a protected
resource and prompt the user to log in before hitting the login page and
upon a successful login would redirect the user to the login page after
they've alre
Adam Gordon wrote:
We're using JAAS for webapp authentication and we've discovered an
issue: If user A is logged in and tries to log in as user B, they stay
logged in as user A.
Couldn't you protect the login form page and action so that they're only
accessible by a session without any valid
Hi-
We're using JAAS for webapp authentication and we've discovered an
issue: If user A is logged in and tries to log in as user B, they stay
logged in as user A. We know how to detect if a user's already
authenticated (we have some static objects stored on the session) but
we're not sure w
12 matches
Mail list logo
