Murray Altheim wrote:
Honglin Ye wrote:
Murray Altheim wrote:
[...]
>>>Can anyone let me how to hide
the xindice from quering using commandline tool?
excellent. Thanks for the solutions
These are just off the top of my head as I type them:
1. write a small proxy to sit between the actual Xindice port and
the proxy (public) port. This could probably be accomplished
with less than a thousand lines of code (I wrote a tiny HTTP
server in about 500-600).
if the person access the proxy port, the request will pass on to
xindice port.
how this thing distinquish between a ok-user and a not-ok-user?
Well, that's your job to do. There's probably a bunch of ways to do
this too. You could either build something simple from scratch or
use an existing system. There are quite a lot of available security
projects on SourceForge, or you could use Apache as a proxy.
2. create an IP access control list to filter access via incoming
IP addresses
the authorized users are distributed over the world, I have no way of
knowing where that request comes from.
3. use a user-based system:
a. via username-password
b. via domain-based filtering
same reason as above
Yes, but this is the most foolproof system. You manage it like any
other password system. And there's lots of code around for this kind
of thing.
4. extend one or two of Xindice's classes to enable data flow based on
any number of factors.
this is good, but if xindice changes, the extension has to follow
Yes, that's always an issue with anything, whether you're using an
extension or not.
5. use a cookie-based system (i.e., if the user query doesn't have
the right cookie, deny service
good for web app, authenticate in app. commandline query not coverd
I'm not sure what you mean by command line. I can launch either a GUI
or non-GUI application from the command line. If it's simply that you
want a simple security solution, there isn't one unless your security
needs are simple. If you want access control lists, you need to build
that, and that will require some infrastructure. None of that infra-
structure would be appropriately *within* Xindice.
by commandline, I mean things provided by xindice and documented by you (I
think it is right person), something like
xindice xpath -c xmldb:xindice://a.server:7777/db/col_a -q "/root[id='3']"
6. encrypt all data stored in Xindice (prior to going into Xindice)
and give the keys only to trusted clients
good solution, i only need to deliver the encrypting key and
de-encrypting tool
to those users
But you really lose a lot of functionality within Xindice.
7. extend the client to require a preliminary handshaking, where
the server challenges the client to produce a hash.
do you mean modify xindice's commandline tool?
As I mentioned above, whether Xindice is launched from the command
line or not, your solution is going to be some combination of modifications
to Xindice (if necessary) and your overall security system (which might
be a part of a proxy, your overall firewall solution, whatever).
8. make the port available only within your LAN/WAN
the port is available inside, i need to hide docs from the people
inside too.
Then you need an access control list, either via IP or more probably
via password or encryption with distributed keys. PGP or something
like that would work. You'd put the encrypted data within a CDATA
section within Xindice. But then you really should be looking at
a different type of database, as an XML database whose entire content
is encrypted is kinda pointless. Unless you were willing to write
indexing and querying schemes that decrypted on the fly. That kind of
thing is certainly a possible scheme, but only one of many, and would
be an external module to Xindice, not part of every Xindice distro.
We don't want to bloat Xindice with things that not everyone would
want (esp. since as I've tried to demonstrate, there's many different
ways to solve a specific problem).
9. use existing proxies to keep out intruders
10. require access only via a downloaded client that uses any number
of secure methods to gain access to the server (hashes, passwords,
etc.)
11. alter the query itself to include a hash prefix. The formula
to the hash is only known to you and trusted clients.
this may be the easiest solution. the hash prefix works like a password.
Yes, and there's probably others too. Have a big cup of coffee and
put on your thinking cap... you'll come up with something. :-)
I dunno. This is five minutes' effort. I'm sure I could think of
more. I'm sure others could too.
Murray
