RE: Security Realm Limitations (More on protecting PDF documents.

[br...@zethcon.com]

> 
> This is probably off-topic, but why would you want to do this on the
> application server level?  How will you handle changes to the
> server.xml or web.xml file?  What if there is an error/typo in that
> file after a change? Will you have to stop/start tomcat for the changes
> to take effect?
> 
> Seems to me the better long-term solution would be to handle access
> control programmatically in your application.  Keep track of users,
> groups, and group memberships in a database...that way changes are
> instantly live and you can easily restrict or delegate permissions for
> managing user accounts and permissions to non-admin, non-root users.
> 


I want to do it programmaticlly! In fact I am in my JSPs - just check for 
a session var & redirect to the logon page if it's not there. But how do I 
protect non-jsp pages, like PDFs without using the security realm?

> John Turner
> jturner@NOSPAM.aas.com
> http://www.aas.com
> 
> 
> -----Original Message-----
> From: Brad Rhoads [mailto:brhoads@zethcon.com]
> Sent: Friday, June 28, 2002 4:07 PM
> To: 'Tomcat Users List'
> Subject: Security Realm Limitations (More on protecting PDF documents.)
> 
> 
> 
> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:  
> <ma...@jakarta.apache.org> For additional
> commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>