Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 23254 invoked from network); 1 Apr 2002 18:48:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Apr 2002 18:48:26 -0000 Received: (qmail 12438 invoked by uid 97); 1 Apr 2002 18:48:08 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 12377 invoked by uid 97); 1 Apr 2002 18:48:07 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 12331 invoked from network); 1 Apr 2002 18:48:07 -0000 From: "Phase Web and Multimedia" To: "Struts User" , "Struts Developers List" Subject: Security Solution Date: Mon, 1 Apr 2002 11:49:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020401083148.N96552-100000@icarus.apache.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: