New Module: Recaptcha FormField

[Ingo Schommer]

"stop spam. read books."

documentation: http://doc.silverstripe.com/doku.php?id=modules:recaptcha
download: http://open.silverstripe.com/browser/modules/recaptcha/tags/0.1

have fun crowdsourcing your captchas! :)

[Michael Gall]

As a side note: Is there a reason you do the config likethat rather than doing in _config.php RecaptchaField::setAPIKey("ADSFADSF"); ?

[Ingo Schommer]

good point, as the keys are bound to a domain, it will be quite rare
that you want to create two instances of those fields with different
keys - i'll change it in 0.1.1 (and collect a bit more feedbac)

On Jan 31, 5:37 pm, "Michael Gall" <mich...@wakeless.net> wrote:
> As a side note: Is there a reason you do the config likethat rather than
> doing in _config.php RecaptchaField::setAPIKey("ADSFADSF"); ?
>

> On 1/31/08, Ingo Schommer <ingo.schom...@gmail.com> wrote:
>
>
>
> > "stop spam. read books."
>
> > documentation:http://doc.silverstripe.com/doku.php?id=modules:recaptcha
> > download:http://open.silverstripe.com/browser/modules/recaptcha/tags/0.1
>
> > have fun crowdsourcing your captchas! :)
>

> --
>
> http://wakeless.net

[Michael Gall]

Thinking about it thouh, that will always AutoLoad the RecaptchaField class.... possibly not what is wanted.

you could do that in the actual RecaptchaField.php at the end a static call like

 

if(is_defined(RECAPTCHAPIKEY)) RecaptchaField::setAPIKey()

 

Kinda the best of both worlds.

 

On 1/31/08, Ingo Schommer <ingo.s...@gmail.com> wrote:

--

http://wakeless.net

[Matt Peel]

I wonder if it might be better to use protected final static's for the
static properties like $api_server, $api_ssl_server, $api_verify_server
and $recaptcha_js_url.

I doubt these are going to change, and it's probably more secure to use
things that will make PHP fall over and die if they're changed by some
remote execution. If the URLs do change, you can just release a new
version of the module (which you would have to do anyway, presumably).

I can't remember if PHP lets you chain 'protected final static'
together, or if it can only be 'final static' but either way nets you
the same result. It's pedantic, but secure development sometimes is :-)

Matt.

[Sigurd Magnusson]

Yea, I love recaptcha.

Ingo, perhaps it could also add a recaptcha field/option to
userdefinedform and you could document or add a feature on how to easily
add it to forum or blog posts. (Doesn't blog have a method to choose the
type of spam-preventing?)

bet you're wishing you never did this now! :P

Will blog... :)

Sig

[Ingo Schommer]

thanks for this super-fast feedback!

@matt: there might eventually be different recaptcha servers (alike
openid), i don't see direct security benefit in making those statics
final either (if an attacker can write statics within silverstripe
code, you've got a whole host of larger problems...).

@sig: all good ideas ... err, make a ticket for it ;D (i just had time
to do this because it was client-related in the first place)

[Sam Minnee]

This is a limitation of our config system generally. In my opinion,
it would be best to stick with the conventional configuration
architecture, even if it does add an unnecessary auto-load. Adding a
custom-hack for a single module is just going to confuse things.

Having said that, maybe it's time to think about a new way of dealing
with configuration settings. The current config system has the
following options:

* You wind up getting unnecessary auto-loads on every page request.
* You have to write a lot of scaffold to allow for configuration
options.
* It's near-impossible to write a web-interface to edit configuration
options.

The main advantage of the current system is that it's scriptable. You
can put a config option in a conditional, such as:

if(Director::isDev()) RecaptchaField::set_api_key("dev_key");
else RecaptchaField::set_api_key("live_key");

I think that it's important that we still allow for this kind of
construct, but we should recognised that the majority of config
options don't need this kind of setup.

We could move towards having a file such as silverstripe.ini a more
traditional "configuration file" set-up, where we have namespaced
configuration items:

[RecaptchaField]
api_key = XXX
other_parameter = YYY

We could potentially choose to use parse_ini_file() to read these
files http://nz.php.net/manual/en/function.parse-ini-file.php.

Note that ensuring the security of the .ini files is critical. That
could potentially be done with the .htaccess file, or by making
the .ini file a .php file that outputted no content.

We could leave support for the _config.php files there for developers
to do special things with config, but we would move most of the
configuration burden to the config files.

We could potentially also have built-in support for silverstripe-
dev.ini, silverstripe-test.ini, silverstripe-live.ini. Of course,
these would be included after silverstripe.ini and _config.php, as
these files would be instrumental in determining which
environment_type you were set to.

I would like to hear everyone's thoughts on the configuration system;
it would be good to do a revamp of this for v2.3.

[Sigurd Magnusson]

My only issue with
[section]
option=setting

Stuff is that it takes us away from PHP code's ability to be
programatically powerful; there's no logic you can wrap around that. Do
the benefits of the above syntax outweigh limiting your flexibility?

Sig

--
Thanks,
Sigurd
--

Sigurd Magnusson | Chief Marketing Officer
SilverStripe
http://www.silverstripe.com

Office: +64 4 978 7332
Cell: +64 21 42 12 08 (NZ), or 503 475 1928 (USA)
Skype: sigurdmagnusson

We're finalists in the global Packt Publishing CMS Awards! If you like our free software, then we'd appreciate a vote:
http://www.packtpub.com/article/most-promising-open-source-cms-award-final-silverstripe

[Sam Minnee]

Generally speaking, the programmatic flexibility is only used for a
small proportion of the overall configuration. And by far the most
common "programmatic flexibility" is to have different behaviour on
stage/dev/live sites.

For that reason,

* We still allow for _config.php files, and we just recommend people
only use them when they *need* that flexibility.
* We have silverstripe-dev/test/live.ini support.

[Sam Minnee]

Another option is to keep the config in _config.php. We have a method
like Config::set() to load the configuration variables.

Config::set("RecaptchaField.api_key", "xxx");

And if we wanted to implement a web-based configuration system, we
could do so with a block along the lines of this:

/* AUTOCONFIGURE START */
Config::set(array(
"RecaptchaField.api_key" => "xxx",
"RecaptchaField.other_key" => "yyy",
));
/* AUTOCONFIGURE END */

On Feb 1, 1:17 pm, Sigurd Magnusson <sig...@silverstripe.com> wrote:

[Michael Gall]

I really think we should try and work a system that doesn't need to do those unnecessary autoloads, I'm not sure how that could work, possibly a callback from the Autoload system, to the config system. I've been doing a lot of investigation into performance/memory and that certainly can be an issue.

--

http://wakeless.net

[Ingo Schommer]

i've made a new thread for this discussion, as its moving in a quite
different direction from the original topic.
http://groups.google.com/group/silverstripe-dev/browse_frm/thread/8c538865170022d

#################
0.2 release
#################

# changelog
- switched to static configuration of API keys
- session-based errors passed through to recaptcha
- using custom HTTP POST generation (HTTP::sendPostRequest() has
performance issues here)

# changeset
http://open.silverstripe.com/changeset/48965

# download
http://silverstripe.com/asset/downloads/modules/recaptcha-0.2

On Feb 1, 1:50 pm, "Michael Gall" <mich...@wakeless.net> wrote:
> I really think we should try and work a system that doesn't need to do those
> unnecessary autoloads, I'm not sure how that could work, possibly a callback
> from the Autoload system, to the config system. I've been doing a lot of
> investigation into performance/memory and that certainly can be an issue.
>

[Ingo Schommer]

argh

# download
http://silverstripe.com/assets/downloads/modules/recaptcha-0.2.tar.gz

[in...@lemon8.nl]

Thanks Ingo, great stuff!

Could you give me some pointers on integrating this into User Defined
Forms? I wouldn't mind to spend some time trying to do this...


On Feb 1, 3:08 am, Ingo Schommer <ingo.schom...@gmail.com> wrote:
> argh
>
> # downloadhttp://silverstripe.com/assets/downloads/modules/recaptcha-0.2.tar.gz

[Ingo Schommer]

hey fuzz, it'd be awesome to have this in a UserDefinedForm!
you can have a look at other editable fields for sample
implementations, e.g. sapphire/forms/EditableEmailField.php.

unfortunately you have to subclass EditableFormField/DataObject to get
the base functionality,
which means you can't just extend RecaptchaField or "mix in"
EditableFormField.
i'd suggest you recreate the same API and try to re-use existing code
where possible:
EditableRecaptchaField::populateFromPostData() ->
RecaptchaField::validate()
EditableRecaptchaField::getFormField() -> RecaptchaField::Field()
etc.

you have to force the field to be "required", otherwise the
RequiredFields validation is never triggered.

the minimum configuration you need is two fields for the public/
private API keys,
although they could optionally be set by an admin in _config.php to
make integration easier for users.