struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Pitman <npit...@interlink.net>
Subject Re: Security Solution
Date Mon, 01 Apr 2002 20:31:16 GMT
Hello Brandon,

This might be interesting to me, but then I'm a newbie so I'm not sure 
whether I should be interested.

As an alternative to posting sources here, you could create a project on 
SourceForge.net.  It would relieve this list of the specific traffic.

One aspect of documentation that I find particularly lacking is an 
"appropriateness" section.  I expect it to be missing in commercial 
documentation (because no one wants to lose a sale).  I have been 
searching open source for the last few months.  I really have to dig 
into each project to understand whether it is appropriate.

Could you provide:
1) indications for use
2) contra-indications against use
3) known complementary technologies (those it depends upon, those that 
depend on it, those with a synergistic relationship)
4) known competative technologies (ones where I have to choose the one 
feature set or another)
5) a comparative feature list (including versions of competitors).

Ok, it sounds like I want a month of the marketing department.  A line 
or two would suffice.  Indeed, "unknown" would help - it would at least 
tell me that I'm on my own.


Phase Web and Multimedia wrote:

> Greetings,
> 
> I wanted to offer some code if anyone is interested. I have seen many
> discuss security on archives and wanted to offer an alternative to container
> managed security.
> 
> I spent some time weighing out whether to use container managed security or
> not and came to the conclusion that I would use a filter for security. There
> were several inflexibilities in the spec for container managed security. I
> wrote a security filter that functions very similar to container managed
> security. It has an xml config file that is used to protect urls. There are
> a few differences in the config and how you define protected areas and where
> you are directed.
> 
> Basically there are three areas of greater flexibility.
> 
> 1) you can define several security-constraint groups with different login
> pages.
> 2) you can login easily without having to hit a secure page first
> 3) you can set up an app specific security realm. (This can also be
> considered a limitation if you are maintaining cross context security, but
> you could easily tie into a larger security system if this is needed)
> 
> Anyways, it is not the "standard" but it functions well and gives greater
> freedom. I found container managed security to be a greater "hack" job when
> I wanted to accomplish my goals. If anybody is interested I can post it for
> review. It is certainly not mature and the code is fit for my current
> situation with an eye to greater flexibility. I think that it could provide
> a good starting point for a cross-container simple alternate solution to the
> current container managed security.
> 
> P.S. I have to improve the documentation :-)
> 
> Thanks for your time,
> Brandon Goodin
> Phase Web and Multimedia
> P (406) 862-2245
> F (406) 862-0354
> mail@phase.ws
> http://www.phase.ws
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
> 
> 


-- 
Neil Pitman
npitman@interlink.net
+1.514.863.5465


--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message