> you can use a filter to do this programatically. You can use
> request.isUserInRole("myrole") to see if they are in a given role.
>
What do you mean my "usa filter"?
Can you point me to docs/examples?
> 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:brhoads@zethcon.com]
>> Sent: Friday, June 28, 2002 5:29 PM
>> To: 'Tomcat Users List'; augustd@codemagi.com
>> 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:augustd123@yahoo.com]
>> Sent: Friday, June 28, 2002 4:16 PM
>> To: Tomcat Users List; brhoads@zethcon.com
>> 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 <brhoads@zethcon.com> 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:tomcat-user-unsubscribe@jakarta.apache.org>
>> For additional commands, e-mail:
>> <mailto:tomcat-user-help@jakarta.apache.org>
>>
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org> For additional
> commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
|