Session store

[marsh8]

CAPTCHA_STORE setting added.

CAPTCHA_STORE = 'DB' (default). Captcha info stored in CaptchaStore model (same as before).
CAPTCHA_STORE = 'SESSION'. Captcha info stored in SessionStore (sessions should be enabled).

Known issue: django will made new migration after changing CAPTCHA_STORE setting and running makemigrations.

upd: django 1.4 compatible.

[mbi]

Hi, thank you, this looks interesting! What are the advantages of storing the captcha in the session instead of the database? Performance?

Also, would you consider including a couple tests, covering the bits affected by the patch?

Cheers.

[marsh8]

Hi, and thanks for useful captcha app.

It should have better performance with some sessions settings (Memcached sessions for example).

I'll write additional tests after passing all of Travis' checks.

[marsh8]

upd: minor fixes and few tests.
known issue: django 1.4 don't have SessionStore.clear_expired() function. store.remove_expired() will be skipped for django 1.4.

It would be nice if you could add this code to the installation package.

[mbi]

Hi, just an update on this: I'm working on this pull request, but it's more complicated than it seems. Basically what I'd like to do is set CAPTCHA_STORE = 'SESSION' in the testproject settings and make sure the tests still pass using this backend. They currently do not, but not necessarily because your code isn't working.

[marsh8]

Hi.
I tried that too, but it didn't go so well. Storages broke some test (differences in structure, SessionStore can't use objects.get(...), additional characters in hashkey etc). It's either rewriting code or making new tests.
I took two previous tests, made some minor changes in code and switched storage from 'DB' to 'SESSION' in these tests on a fly (it's testFormSubmit and testWrongSubmit in StoresCase class).
In the end it was test that checks both 'DB' and 'SESSION' storages in a single run without changing settings of test project.
It worked better than changing settings for whole test project.

[ealogar]

Are you going to aprove this PR? The feature seems interesting to have...

[mbi]

@ealogar not in its current state, sorry.

[ealogar]

@mbi Thanks for your response,
do you see interesting to add a setting to override the CaptchaStore model and provide a custom one?
CAPTCHA_STORAGE_MODEL = getattr...
In this way people would be able to change django orm to a storage in mongodb (as my case). If you see interesting I would launch a pr...

[mbi]

@ealogar sure, granted it comes with tests and everything that currently relies on the Django ORM still works :)

[ealogar]

@mbi I am working on it. I will add a test with an in-memory storage dao. Up to people the dao they provide, just fine if they follow The BaseCaptchaDao duck-typing

[vstoykov]

I see that there is another implementation (but using cache instead) in #103.

Probably something combined from both will be very good.

[9mido]

Any update on this or on #103 ? I would very much prefer to use anything other than the database to store the captchas temporarily or better yet redesign the app to not even need to store the captchas at all somehow? Storing it in cache might also be costly to the hardware especially if there is not a caching invalidation strategy.

[veto8]

Yes, I would also like this option, as I want to keep my relational database small and portable.

[veto8]

Hi, thank you, this looks interesting! What are the advantages of storing the captcha in the session instead of the database? Performance?
... for me, it's not to "contaminate" the sql database