I have moved all JSP's under WEB-INF directory (e.g.
/WEB-INF/pages/login.jsp), and this solution seems to work perfectly on my
local environment with exploded directory structure. However, Struts seems
to not be working at all when we package and deploy an ear file (before I
moved the jsp's it ha
mojoRising wrote:
Thanks. That's interesting. I am using Weblogic9.2, and I seem to have no
problem using the request object in the jsp( for getParameter at least). I
am wondering what type of request object manipulation, as you are referring
to, may cause issues?
I don't recall specifi
Thanks. That's interesting. I am using Weblogic9.2, and I seem to have no
problem using the request object in the jsp( for getParameter at least). I
am wondering what type of request object manipulation, as you are referring
to, may cause issues?
Jeromy Evans - Blue Sky Minds wrote:
>
>
> Th
I use Acegi security to make sure that all of my pages are secure. I
find it very flexiable, but not always easy to configure.
If you are already using spring as you IoC, then you might as well take
advantage of Acegi.
Jeromy Evans wrote:
I've been told that some older containers don't allow
Plus: nothing under WEB-INF can be referenced by a browser, so JSPs
stored there can't be called directly.
Minus: nothing under WEB-INF can be referenced by a browser, so JSPs
stored there can't be called directly... :-)
It depends on your requirements. But generally you will want to route
r
I've been told that some older containers don't allow you to forward to
JSP's behind /WEB-INF. It wouldn't surprise me.
Other than that I've found Ian's suggestion to be the most effective way
to ensure users can't access JSPs directly, IMO a must for Tiles, html
fragments and any page using str
Is this considered the Best Practice: Keeping all JSP's under the WEB-INF
directory? We have not done that on my project, I am curious if there are
plus' and minus' to this?
Thanks,
John
The easiest way is to always have the user call an action to get a JSP,
even if it is a simple page. You
The easiest way is to always have the user call an action to get a JSP,
even if it is a simple page. You then also ensure that all data
necessary for that page has been obtained. The, by placing the JSP's in
the WEB-INF directory you will prevent access directly from a browser
(only from the
The easiest way is to always have the user call an action to get a JSP,
even if it is a simple page. You then also ensure that all data
necessary for that page has been obtained. The, by placing the JSP's in
the WEB-INF directory you will prevent access directly from a browser
(only from the
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
Hi,
thanks for the input - I actually meant authorisation and not
authentication. I'll give it a try.
Tom
VAN BROECK Jimmy wrote:
Hi,
I wouldn't do authentication via Aop and interceptors,
but authorisation is perfectly feasible, that's what we do in our project using
Spring and aop.
Greetings
J
It is certainly possible, however your old methodology could just as
easily be used by creating a baseAction class and then extending that
class. {
Al
-Original Message-
From: Tom Ziemer [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 07, 2005 9:58 AM
To: Struts Users Mailing List
Subje
Hi,
I wouldn't do authentication via Aop and interceptors,
but authorisation is perfectly feasible, that's what we do in our project using
Spring and aop.
Greetings
Jimmy
-Original Message-
From: Tom Ziemer [mailto:[EMAIL PROTECTED]
Sent: donderdag 7 april 2005 16:58
To: Struts Users
24 matches
Mail list logo
