--- bookie/www/setup.html 2002/07/06 00:44:21 1.11 +++ bookie/www/setup.html 2002/07/14 09:36:35 1.12 @@ -1,103 +1,65 @@ -Setup instructions for compiling and running Bookie: - -

-If you're just browsing or don't need to edit files directly, you can look -at Bookie through the web interface. - -

-If you want to contribute to Bookie or compile it, then you should grab a -CVS client and set up a workspace for bookie. -

- -

-You download bookie by doing this (you only need to login once, the password + + + + + + +Setup instructions for compiling and running Bookie: +

If you're just browsing or don't need to edit files directly, you can +look at Bookie through the web interface.

+

If you want to contribute to Bookie or compile it, then you should grab +a CVS client and set up a workspace +for bookie.

+

You download bookie by doing this (you only need to login once, the password is guest). Please use the prune option when checking out and updating, since -the CVS tree has a lot of dead branches in it. -

- -
- cvs -d :pserver:guest@mozdev.org:/cvs login
- cvs -d :pserver:guest@mozdev.org:/cvs co bookie -P
-
- -

-The java client is in /clients/swing. There is an -ant script that should compile -everything. The client depends on Jena, Apache XML-RPC, Log4J and Xerces. -All the libraries should be available in lib. The client's main class is -com.tersesystems.bookie.client.Client. Downloading -client.jar will give you -the classes, source code and javadoc to play with. -

- -

-The java server is in /server. Again, the -ant script that should compile -everything. The server currently depends on JTidy, Marquee XML-RPC, -Jisp, Servlet 2.2, Log4J, and Xerces, which are all available in lib. The -server's main class is com.tersesystems.bookie.service.xmlrpc.BookieServlet. -

- -

- The server will create four files on initialization in the current directory: -

+ These databases contain all the information needed for the server to work. + Deleting these files will cause the server to start off fresh. +

The server does not attempt to limit multiple logins on the same account from different servers. However, care should be taken with this feature, - as there is no facility to distribute messages between clients that a - branch has been deleted. -

- -

- Bookmarks are cached on the server, but since bookmarks are unique to - each client this isn't that much of a win. Performance seems okay for now - (and if anything seems bound on the XML - processing and IO overhead). Database operations are not transactional. -

- -

- The server uses an MD5 hashed password for authentication of the client. + as there is no facility to distribute messages between clients that a + branch has been deleted.

+

Bookmarks are cached on the server, but since bookmarks are unique to + each client this isn't that much of a win. Performance seems okay for +now (and if anything seems bound on the XML processing and IO overhead). + Database operations are not transactional.

+

The server uses an MD5 hashed password for authentication of the client. Once authenticated, the server maintains a session based off the IP address - of the client. All data is sent in the clear, and as such the passwords and - XML-RPC information may be - packet sniffed. - Even if the attacker does not know - the clear-text password, he can still send the MD5 hash to be authenticated as - the user. Unfortunately, XML-RPC does not cover - security and session management - very well; if there are any new RFCs I would love to hear about them. One - possible RFC is Jim Flanagan's - proposal, but this requires - the use of HTTP digest - authentication, which I believe most clients don't - support. -

+ of the client. All data is sent in the clear, and as such the passwords +and XML-RPC information may be packet sniffed. + Even if the attacker does not know the clear-text password, he can still +send the MD5 hash to be authenticated as the user. Unfortunately, XML-RPC +does not cover security and +session management very well; if there are any new RFCs I would love to +hear about them. One possible RFC is Jim Flanagan's proposal, but this requires + the use of HTTP digest + authentication, which I believe most clients don't support.

+
+ +