bbs.spamgourmet.com

I'll try those modules tomorrow....

I've got the modules installed on the mail machine. I've at least nominally got XMLRPC::Lite installed on the web machine, although I probably don't have all the dependencies in place. I'm pretty optimistic about that, though.

Josh,

Is it possible for me to obtain an ssh login on the web server (non-root of course) in order to test the client-server setup?

I can do some tests on my own machines, but as you know, there are always differences.

did you get the email I sent?

Josh,

I got your email. I found a way (two, actually) to perform the remote call. Very busy, will append later. Sorry for being in short shrift mode.

far be it from me to think other people are too busy

I'll begin work on the UI for getting the address to send to.

Hello guys,

The captcha server is ready. I installed it on the web server in the ~sgserv/captchasrv-1.0 dir. Take a look at the README. It's currently running. Ping me if you cannot figure out how to use it.

it really works!

So, at the risk of appearing blockheaded (never stopped me before), I'd like to rough out how we make this work here.

cgserv (that's short for captchaserv) works like a web server and gives you a cool image in response to an http request that includes the word that will be contained in the image -- right?

the sg webserver would figure out what word it wants to use, then use lwp or something to make the request to cgserv and get the image -- it would then make up a name for the image file, save it on the webserver, and present it to the user as part of the sign-up page? That is, the user page image tag-url will go to a real image file on the spamgourmet webserver rather than to the cgserv url?

cgserv (that's short for captchaserv) works like a web server and gives you a cool image in response to an http request that includes the word that will be contained in the image -- right?

Right.

the sg webserver would figure out what word it wants to use, then use lwp or something to make the request to cgserv and get the image -- it would then make up a name for the image file, save it on the webserver, and present it to the user as part of the sign-up page? That is, the user page image tag-url will go to a real image file on the spamgourmet webserver rather than to the cgserv url?

Yep, that's the principle. The captchaserv directory even has a file with a couple of perl routines to help pick the word.

My first reaction when I read your message was to think "Wait, why do we have that intermediate stage? Why do we have to slurp the captcha from cgserv to the web server instead of just putting the cgserv URL on the user registration page?" Well duh, of course: because right now, the cgserv URL contains the captcha word. Some security.

So with the current scheme, we have that intermediate stage (the captcha copied from cgserv to web server) which is a useless burden. Why not suppress it? Here is what I suggest. I modify the captchasrv code so that it makes up a random captcha file name and saves the captcha to that file. Then it returns the name of the file -- just the name -- to the caller on spruce.

Since the machine on which cgserv runs (gourmet) has its own HTTP server, all you now have to do to show that image to the user is to put the captcha URL (with the random name) in an image tag in the user registration page. Of course, cgserv has to put the captcha image in a web-accessible dir, clean up old images, etc. All things that would have to be coded on spruce in the current scheme anyway.

This would save some CPU and bandwidth.

Shall I do it?

That'll work -- I'll set up images.spamgourmet.net to point to a folder in the sgserver directory for the images. Don't worry about cleanup right away if it's a pain, I can just do that manually every so often.

OK, let me know when images.spamgourmet.net is set up. Also, let me know the max size of the image directory. Automatic cleanup is simple, don't worry.

it's up. Don't worry about the size -- we can allocate gigs and gigs if need be.

Guys,

The new version is up. See ~sgserv/captchasrv-1.1 on gourmet. It's currently running on its default port.

The image file can be named after the username (rather than a randomly generated string). This will simplify debugging for registration issues.

Amit,

We already discussed that, I believe. I reread this thread, and there was a very interesting discussion around Nov 6. We decided that we would need to append the username with a random or timestamp suffix.

Josh, I draw your attention to Amit's idea for checking the quizword:

We can build a string by concatenating a secret key and the quizword returned by catchagen, create a hash, and send the hash to the user as a hidden value field. Without the secret key, the chances to find the right hash are pretty slim.

You don't really need the user name in the image name for debugging, because the captcha server returns the name of the generated image anyway. However, if you really think it's necessary, I could change the server to introduce this change - the calling convention would have to change too.