you can use a filter to do this programatically. You can use
request.isUserInRole("myrole") to see if they are in a given role.

you can reload web.xml by using manager to stop/start(not reload) the
application. This will only affect the requested context as opposed to
restarting tomcat. 

Charlie

> -----Original Message-----
> From: Brad Rhoads [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 28, 2002 5:29 PM
> To: 'Tomcat Users List'; [EMAIL PROTECTED]
> Subject: RE: Security Realm Limitations (More on protecting PDF
> documents.)
> 
> 
> Is there an API that so I can update the web.xml programaticly?
> 
> Other options that wouldn't require restarting Tomcat? While 
> the # of PDFs
> will not change often, access will. I assume I'd also have to 
> restart Tomcat
> to change <auth-contraint>s; It looks like I'll have to 
> create a role for
> each user.
> 
> Along the same lines, it looks like the JDBC Realm let's you 
> specify a DB
> table for users, but for resources and their roles???
> 
> -----Original Message-----
> From: August Detlefsen [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 28, 2002 4:16 PM
> To: Tomcat Users List; [EMAIL PROTECTED]
> Subject: Re: Security Realm Limitations (More on protecting PDF
> documents.)
> 
> 
> You can define a different <security-restraint> for each PDF, and
> assign the required roles to that:
> 
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>PDF for Group One</web-resource-name>
>       <url-pattern>/group_1_only.pdf</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>        <role-name>group1</role-name>
>     </auth-constraint>
>   </security-constraint>
> 
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>PDF for Group Two</web-resource-name>
>       <url-pattern>/group_2_only.pdf</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>        <role-name>group2</role-name>
>     </auth-constraint>
>   </security-constraint>
> 
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>Shared PDF</web-resource-name>
>       <url-pattern>/everybody.pdf</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>        <role-name>group1</role-name>
>        <role-name>group2</role-name>
>     </auth-constraint>
>   </security-constraint>
> 
> 
> This will make for a big, unwieldy web.xml though, and it will require
> restarting tomcat every time you add a new PDF (do they change
> frequently)?
> 
> Do security constraints follow symlinks? Maybe you could create two
> protcted directories (group1, group2) and then symlink the 
> files from a
> central repository?
> 
> 
> 
> --- Brad Rhoads <[EMAIL PROTECTED]> wrote:
> >
> > I've determined that I can use security realms to protect PDF
> > documents.
> > (See 
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/realm-howto.html
> if you
> happen to be getting started on this problem).
>
> I need to be able to give access to one set of pdfs to one group of
> users,
> and to different sets for other groups of users. It looks like I can
> accomplish this much by creating separate directories for each group
> and
> setting up a role for each group. But I have two related problems
> left:
>
> 1. The same PDF may be available to multiple groups. It seems that I
> would
> have to maintain duplicate copies of the PDFs, one for each group.
>
> 2. This group level security provides the base list of available
> PDFs. I
> need to be able to take away access to documents from certain users
> within a
> group.
>
> Suggestions? Or better yet examples?
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to