Interesting, right now it uses Drupal's variable_get() to retrieve the keys. But if you're using multiple domains under the same Drupal database, with the same content, this solution will not work, since it will just load the one set of keys. If you think of any solution around it, I'd be most interested in hearing about it.

Well, yes... one database but multiple domains. At least for the time being.

I'm relatively new to Drupal (less than half a year, so not really competent in this area) but learning a lot and definitely not unwilling to help out here :)

I have an idea or two, though. Just had a look at the variables table. Perhaps, instead of storing strings for the keys, an array could be stored there. Something like this:

Or, when not using an array, the current variable names could be prefixed/suffixed by the domain name. For the "normal" user nothing needs to change or perhaps "default" could be used as the domain name? By querying $_SERVER['HTTP_SERVER'] it would be clear which keys to actually retrieve.

How to realise the key input in a form, though, I have no clue right now.

Would you think it's worth doing? Feasible?

Kind regards,
Marco

After doing some brainstorming, I now know how to support multiple domains, under one databsae, with different reCAPTHCA keys. I'll start work on it once I get the time. Shouldn't take that long.

That's just great news and highly appreciated. Thank you very much!

I have some good news, and I have some bad news:

Good news: Got it working
Bad news: If your domain is too large, it breaks the system.

How the solution works: Instead of just storing the private and public keys in the variables tables in the database, it puts $base_url in there as well.
recaptcha_private_key becomes 'recaptcha_' . $base_url . '_private'.
recaptcha_public_key becomes 'recaptcha_' . $base_url . '_public'.

Although it does work, it breaks the system if your base url is large, because the name field in the variable table is restricted to 48 characters. A way around this is to facilitate the creation and deletion of an entirely new table in the database. Does this really warrant the creation of a new table though?

We could also make the name smaller.... 'recaptcha_' . $base_url . '_prv' and '_pub', maybe? Then that would let us have the $base_url be 34 characters long.... Might help.

Do you think we'd have to split this up into a new database table? Or just use the variable_get/set solution?

Sorry, been away for a few days...

For me personally, the set/get would completely suffice. But of course, I can't speak for other users here. So maybe the best/easiest solution for now would be to use that and wait for feedback from others? I'm not even sure how many other users would even need this feature...

Kind regards,
Marco

drumlin, I think you can apply your idea by placing code like this in the settings.php files for each domain.

No, unfortunately not. Both domains point to the same Drupal installation (and same database and so on) and therefore use the same settings.php as well...

Does it work if you separate the settings.php files?

sites/mysite1.com/settings.php:

sites/mysite2.com/settings.php:

I just tried it, and it does work. Thanks a lot for the tip, drumlin.

Sending some thanks my way is okay with me. I mispelled recaptcha so maybe I got an automatic disqualification. :(

Haha, thanks christefano. Now is this a feature that should be put right into the reCAPTCHA module's UI itself?

I can go either way myself, but when I think about new admins who are starting out my vote is definitely for a UI. New admins might have a problem editing their settings.php file ... but then again a new admin will learn things pretty fast by running a multisite setup. I'm not 100% sure, but I'm leaning towards a UI (as long as you have time and willingness to code it).

Let's make it easier for everyone rather than a trial by fire. Until then, the settings.php method should probably be in the docs.

Yeah, that should do for now.

If anyone has any good ideas on how this would be implemented from the user administration stand point, please be my guest. Right now, I think modifying settings.php is the best solution.

Just run into the same issue myself. We are running various domains all pointing to the same virtual host / drupal configuration - so storing the captcha keys in the settings file like you proposed above is not yet an option. I see three ways of fixing it:

1. Not so pretty

Keep the HTML admin frontend and introduce a notation which will allow to enter multiple domains->key mappings. For instance:

Assumptions:

• Multiple Keys are separated by \n
• Keys may not containt " and : Chars
• The key will be determined in recaptcha.module using the regex provided by the user above and matched against $_SERVER['SERVER_NAME']

Options:

• make things simpler by not using regex expressions. We would just do an case-insensitive "ends-with" comparison:
  (substr_compare ($_SERVER['SERVER_NAME'], $myDomainName,-1 , strlen($myDomainName),true) == 0)

2. Slightly better

Use an multidimensional associative array in settings.php:

Options

@see 1, not using regular expressions to make things easier

3. As it should be

Well, at least as it appears to me, the best solution would be to introduce a new preferences table / schema in the database and store the mapping over there.
This would require some CRUD Administration Frontend hacking so one could add as many domains and keys as needed. I'm not familiar with the UI-Preferences and Schema API of Drupal yet, so I have no idea how difficult this might get to implement this.

I could provide you with patches or SVN commits for solution 1 or 2 until monday next week. Not sure about the 3rd one.

Cheers!
Paul.

What about using keys_api? It works great for the Gmap module Google keys. I'm hoping to see this functionality for recaptcha and keysapi and then all supported by the domain module, so that we really can forget about all the hassles with keys.

To be honest? I did not even know there is such a thing. After glancing quickly over the sourcecode it might be the way to go, at least for a intermediate solution. The keys_api seems to be still beta which usually bounces me of of using a module for a production environment. On the other hand the source looks simple enough not to expect any bad surprises.

My point is: I need this kind of functionality ASAP. Being a developer myself, i have no problem with getting my hands dirty and do it by myself - but I would rather like to make the changes in a way where not only I but also the official module release could benefit from this. Therefore I would like to see one of the module maintainers giving me a comment which solution they would like to see, if they want me to implement this, or would like to do it by themselves.

Thanks for the hint!

I'm in a similar position - I need this functionality asap as I'm hoping to rollout the domain module and recaptcha isn't aware of multiple domains. I'm in comms with agentrickard (the developer of domain and an incredibly capable developer) on this particular issue so I'll send him a chaser and see where we're at. He didn't think it was much work and I was even prepared to use some of our charity funds to fix it! If anyone else would like to chip in for development costs we'd be very grateful.

Cheers, Stephen

In the domain access world, just use Domain Configuration (supplied module) and add an implementation of hook_domainconf() to the recaptcha module.

http://therickards.com/api/function/hook_domainconf/Domain

Domain Configuration works -- similar to this thread -- by inserting a dynamic variable lookup function into settings.php.

See http://therickards.com/api/file/domain_conf/settings_domain_conf.inc/Domain

You could do something similar for ReCaptcha with a small database table, storing the domain_id or a lookup string, and key value.

Remember that settings.php is a PHP file, so it can contain run-time code.

We've done this in the past, using settings.php:

Moving this stuff to a user interface would be nice though. Although I'd rather not make reCAPTCHA depend on another module, it would be nice to have the ability to use its functionality if it exists. For example, we could have it use what's there now, and then provide more advanced configuration of the domain keys if Keys API is there.

@Rob

So I presume you are more into the solution 3 I proposed? I'm pretty neutral about this. I could either use the settings.php like you did, or get into Drupal development and figure out how get it done right. What about the "not so pretty solution"? This would not require any DB schemas to be created or any usage of 3rd party modules. After adding some help text and form validation to it it might be be even not that terrible in terms of usability.

Mixing the Keys API and the "native" preferences storage might get a bit tricky though. As far I understand keys api provides its very own administration frontend which we would either need to copy or give the user a hint that he cannot use the native preferences panel anymore if he decides to go multidomain with keys_api. Or just maybe I am missing some fundamental concept of hooks and api reusage here.

I'd urge you to install the keys_api and gmap modules on a site and have a look at how it works. Surprisingly simple and effective. On the Gmap config screen, where it normally shows a text field to enter the key, the text field is replaced by the text link "Managed by keys api".

The keys_api is clearly designed for any module to use the hooks it provides.

As for the concern about making "reCAPTCHA depend on another module" - it would only be dependent on keys_api if keys_api was installed - just as GMap can live with it or without it.

IMHO keys_api is one of those very simple and highly useful modules that should be in core.

btw the recommended solution by Rob Loach on March 19, 2008 @ 14:14 works fine with the domain module.

Re: #22

Just a clarification: I am not suggesting that you use Domain Access to handle this. But if you want to support multiple keys inside of DA, there is already a mechanism for that, similar to implementing pathauto or views hooks in your module.

The Domain Access module is also quite large, and I see it taking a while to port to Drupal 6.

I have had a quick look through the Keys API code, and it seems that they make a query to the database every time a key is required. It would be better if they used the variable table, because it's already cached and doesn't require a hit to the database..... I'll submit an issue.

DA is only large because it is a suite of modules -- so the tarball looks large. Working on the port to 6 now.

Domain Configuration, which is relevant here, adds one lookup query -- it basically stores a variable cache per site configuration in order to add $conf overrides in a dynamic fashion. Think of it as option #23 with a UI for managing multiple $conf overrides.

As I say over in the DA issue queue, the solution in #23 is perfectly fine. But if you are using Domain Configuration anyway, then you should use the provided hook, since adding the new code to settings.php duplicates features that already exist.

If all you need to store are the keys, here's the code:

Note that we do not set these fields to "Required' in case the sites wish to share the master site key.

Of course, if you are not using DA, none of this matters.

If would be nice to see the hook implemented here, though.

Other modules can still contain their own GUI for setting an API key through Keys API using the following function:

This allows modules to still allow an API key to be set without leaving their settings page while allowing the Keys API's page to still be able to manage all the keys.

@Rob #28

Originally I had used variables to store the keys (as the README.txt file still makes reference to, I need to change that), but opted not to for some reason. I think it was that I thought it would be better to make a simple database call to get the key vs. storing however many keys as variables when a site only needs the one(s) for it's domain. I don't know performance wise which would be better, but will be willing to make the appropriate changes to use variables instead if need be.

So is this problem already solved in the new version? Or not...

Nevermind, didn't read the full thread...
See also: Keys Feature Request for reCAPTCHA support