Thomas Hamacher wrote:
Laurie,
thanks for the input. I am aware of the container managed security. But as far
as I read in the internet, there is no good solution to use container managed
security together with tiles. So if I wanna have a login-box on every page,
that redirects dynamically to the same page after login I will have some
trouble with the container managed solution. Is this not true or did I
misunderstood anything?
It all depends on exactly what you need to achieve. CMS uses URL
matching, so you'd probably have to have some way to have two distinct
URL mappings for each page, one secured and one not, and have the login
box forward to the secured page -- e.g. if you're on /foo.do, have the
login box forward/redirect to /secure/foo.do. I haven't tried any of
this though, so I'm just guessing at a possible solution.
And another question to the filter-based solution as Leon also recommended:
Does this also work if I have different tiles for one page and some of them
are secured and some aren´t? E.g. I have a tile for an adminMenu, which is
only loaded if I have a user with admin-roles in the session, but which is
part of a usual public tiles-page? This way the servlet-filter will never
find it´s pattern, will it? Is there a simple <logic:present>-Tag combined
with an entry "role" in the action mapping and role-security-check in the
RequestProcessor enough security to be sure, only admins access these
actions? Or is there a way to get around these security-checks, which I
should keep in mind?
Generating different content based on the current user role is really
orthogonal to how you establish user credentials -- that's access
control as opposed to authentication. Once you have the user
authenticated, be it via CMS, a filter or something else, you can then
employ various techniques (including, but not limited to, Antonio's
Dimensions project) to control the visibility of content.
L.
Thank you very much
Thomas
Am Dienstag, 29. August 2006 22:01 schrieb Laurie Harper:
You left container managed security off your list; that's the most
'standard' solution, but isn't necessarily the most portable since parts
are container implementation defined. A filter is probably the most
flexible alternative if container managed security isn't viable, but it
really depends on your exact security requirements.
This is a topic that's discussed alot, both here on the Struts lists,
and in other web development forums, so I'd recommend doing some reading
to get a feel for the solutions others have used and their tradeoffs.
L.
Thomas Hamacher wrote:
Hi everyone,
I think I have a very basic question here, but after spending some time
with google I haven´t found a real solution to this question: What is the
best way to secure a struts webapplication to be sure, that only logged
in users are allowed to do some special action and access some special
pages?
I found 3 possibilities, from what some of them seem to be a solution
from older struts versions.
- Extend the RequestProcessor and do a programmatic security-check
- Use a Filter to do the security check
- Extend all Actions from a customized BaseAction, that does the security
check.
But all of this seems a bit strange to me. As security is a
standard-problem in every webapplication and there are a lot of people
who thought about solutions (JAAS) I can´t believe, that I have to extend
the struts-framework myself to provide some security issues.
So what would you recommend if you want to do a real secure application
with struts, together with tiles and want to be sure, that no pages or
actions are used without permission? And all of this independent, if I
use a Tomcat, a Resin or maybe a JBoss as my struts-web-server.
Do you have any informations, examples or URL´s who have a real solution
to this?
THank you very much
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
