Hi everyone,

I was looking at the requirements for moving from the admin web client to 
supporting command line and API clients (see 
https://issues.apache.org/jira/browse/WOOKIE-262), and was wondering about the 
proxy configuration, which currently uses the Whitelist and AccessRequest 
objects. 

Currently the proxy details are stored in a database and accessed via beans 
using JPA/JCR, however I was wondering about instead configuring the proxy 
using a policies text file, and then having a watcher thread monitor the file 
and reload the settings whenever it is modified.

The "pro" side of this is that for an admin, if you want to change any of the 
proxy policies all you have to do is edit a text file rather than use commands 
or a special client. 

The "con" side would be that policies end up cached in memory rather than 
pulled from a DB as needed which may have a performance impact when looking up 
applicable policies, though we could use JCS (http://commons.apache.org/jcs/) 
if it turned out to be a problem. Another "con" is that we'd need to write code 
for reading and updating the text file (with potential for new bugs...)

Below I've put an example of what a policies file might look like.

-S

##
## Access Policies File
##
## This file is dynamically loaded by Wookie and configures
## access policies for the proxy service, including both
## whitelist (global) and widget-specific access policies
##
## Note that when new widgets are added to Wookie their
## access policy requests are automatically added to this
## file.
## 
##
## The format of entries is widget-uri origin directive
## The widget-uri and origin may be a wildcard (*). To enable
## subdomains, use a wildcard as the first element of the
## origin host, e.g. http://*.apache.org
##
## The default (implicit) policy is to deny all origins for all widgets
##
## Example:
##
## * http://127.0.0.1 ALLOW
## http://www.getwookie.org/widgets/weather http://newsrss.bbc.co.uk ALLOW
## http://www.getwookie.org/widgets/rss * ALLOW
##
## This set of policies would allow access to 127.0.0.1 for all 
## widgets, while the "weather" widget would be allowed to access 
## URLs from  http://newsrss.bbc.co.uk, and the RSS widget could 
## access any URL from any origin.
##

* http://127.0.0.1 ALLOW

Reply via email to