On 16/11/2011 10:58, Scott Wilson wrote:
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...)
IMO the second one is the main con, checking concurrency issues on
modification for example. The whitelist & access requests don't tend to
change a great deal really (and up until now at least), we dont seem to
have lots of those records in the database by default. I can see the
logic in what you propose and your example format below looks (a lot)
like a properties file that the apache web server might read on boot.
(no bad thing)
Paul
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
