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.

 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

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

 "I'm a war president. I make decisions here in the Oval Office
  in foreign policy matters with war on my mind." -- George W. Bush
  http://news.bbc.co.uk/1/hi/world/americas/3470139.stm

 "This is the new Mein Kampf. Only Hitler did not have nuclear
  weapons. It's the scariest document I've ever read in my life."
        -- Dr. Helen Caldicott, referring to the Project for the
  New American Century report entitled "Rebuilding America's
  Defenses: Strategy, Forces and Resources For a New Century"
  http://home.earthlink.net/~platter/neo-conservatism/pnac.html

    "This report proceeds from the belief that America should seek
     to preserve and extend its position of global leadership by
     maintaining the preeminence of U.S. military forces." [op. cit.]

    "[...] and advanced forms of biological warfare that can target
     specific genotypes may transform biological warfare from the
     realm of terror to a politically useful tool." [op. cit.]

 "This is a blueprint for US world domination."
  http://www.guardian.co.uk/comment/story/0,3604,1036571,00.html




Reply via email to