Set session cookie so captcha works the first time

How to exclude the path? I tried to add the path of the image, but this didn't help me.

I tried many paths, but Boost didn't exclude them. Example image_cache/*

Is this still an issue for 6.x? If so, is there a good solution?

Still an issue: http://drupal.org/node/632742
...with no solution I believe.

can someone help please.

+1

I am also having this problem with 1.17. +1

Can I get a list of captchas modules to test against?

Every captchas modules have same problem.
I use "Lost characters".

In the form si hidden atribute:

<input type="hidden" name="captcha_sid" id="edit-captcha-sid" value="4308"  />

and this is in the cache. ;-)

After sending form, user get error message: "CAPTCHA validation error: unknown CAPTCHA session ID. Contact the site administrator if this problem persists."

I mean, this is problem of CAPTCHA module. ;-)

sounds like this might fix it then
#586210: Set session cookie

What if we just put up a drupal_set_message() on webforms with captchas so the boost module wouldn't cache them? (Per the option to not cache pages with errors.)

What if we just put up a drupal_set_message() on webforms with captchas so the boost module wouldn't cache them? (Per the option to not cache pages with errors.)

Those of us who have a tiny captcha on every page of their site would have boost rendered completely useless. If this is implemented, make it optional. I don't want to cache message-pages, but I don't want a message on every page either.

For some reason, I haven't had a problem with the captchas getting cached. They seem to work even when they are cached?

#12 "Those of us who have a tiny captcha on every page of their site would have boost rendered completely useless." agree..
Not sure though how your captchas seem to work.. did you try it when logged out?

subscribe

Finally got around to installing the captcha module & it appears that it works off the session ID. Not caching a page that contains the captcha is not required; it works with the normal page cache. This will be postponed until I get this done #586210: Set session cookie (this will be my top priority).

Looking forward to the solution(s) :)

subscribing

... just curious if there are any updates on this. Does captcha module & boost work together now?

Both are installed and working fine for me now.

That's great news, thank you for letting me know. I will try captcha module again (boost is already installed) :)

Ok.. so here is what I can report.
captcha module does NOT work if the page is cached for anonymous users. First time you send a form it works fine, but if you would like to send the form again, it will not work and there is a message about session and that the code was not entered correctly, then you can re-enter it.
Message in the log: "contact_mail_page post blocked by CAPTCHA module: challenge "Image" (by module "image_captcha"), user answered "2rtqd", but the solution was "undefined"."
Not sure how you got both modules to work together.. The only way I can have captcha work is if its on pages that boost does not cache.

captcha module does NOT work if the page is cached for anonymous users.

Yes... this is what I've run into as well. And Boost ONLY caches pages for anon users. The only temporary workaround, albeit self-defeating, is to have CAPTCHA only use ONE character for its character set. Then the captcha is always the same and no matter what, everyone can get it right. Bots should still be foiled, if they are in fact unable to read the captchas in the first place, no? ;-) The only way a bot could get in is if the designer designed it for your website specifically, using your (constant) single character code, or if the bot is able to read captchas anyway (which would allow it in EVEN if the captcha was multi-character), or if it brute-force attacked your site.

I have experienced no rise in bot-spammed forms from my site after changing my captcha character set to be always "Aa" (case-insensitive).

I have experience absolutely no more errors in real peoples' fulled out form submissions now, even with Boost caching the pages.

I haven't encountered these issues. You can test my site at: www.keghart.com, just pick any article and enter comments. I would appreciate if you can break it so I can fix it...;)
You can enter anything you want, it's moderated and I can remove them later, just enter "Testing" on the subject line.

Thanks for the link. I just went and tested this on your site.. and it works. Not sure how you have made this happen. Can you share your boost settings? or any other settings that might help others to make this work?

from the boost tag added to the page on your site it seems that the page gets flushed when a comment is posted, because if I go back to the URL of the post, the boost tag dates are updated.. So now if I can only figure out how to do this on boost settings...

Do you have "Expire content in DB, do not flush file." checked or unchecked? This could be the setting I guess?

Tried turning off "Expire content in DB, do not flush file.".. still no luck

Thanks for testing it and making me secure that it works. I will try to help make it work for all of you as well.
I am using Boost 6.x-1.18 & CAPTCHA 6.x-2.2.
Please see the attached files for the settings.

Here is the Generated Rules:

  ### BOOST START ###
  AddDefaultCharset utf-8
  <FilesMatch "(\.html|\.html\.gz)$">
    <IfModule mod_headers.c>
      Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
      Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    </IfModule>
  </FilesMatch>
  <IfModule mod_mime.c>
    AddCharset utf-8 .html
    AddCharset utf-8 .css
    AddCharset utf-8 .js
    AddEncoding gzip .gz
  </IfModule>
  <FilesMatch "(\.html|\.html\.gz)$">
    ForceType text/html
  </FilesMatch>
  <FilesMatch "(\.js|\.js\.gz)$">
    ForceType text/javascript
  </FilesMatch>
  <FilesMatch "(\.css|\.css\.gz)$">
    ForceType text/css
  </FilesMatch>

  # GZIP - Cached css & js files
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=2]
  RewriteCond %{DOCUMENT_ROOT}/cache/gz/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz -s
  RewriteRule .* cache/gz/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz [L,QSA,T=text/css]
  RewriteCond %{DOCUMENT_ROOT}/cache/gz/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz -s
  RewriteRule .* cache/gz/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz [L,QSA,T=text/javascript]

  # NORMAL - Cached css & js files
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}%{REQUEST_URI}_\.css -s
  RewriteRule .* cache/%{SERVER_NAME}%{REQUEST_URI}_\.css [L,QSA,T=text/css]
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}%{REQUEST_URI}_\.js -s
  RewriteRule .* cache/%{SERVER_NAME}%{REQUEST_URI}_\.js [L,QSA,T=text/javascript]

  # Caching for anonymous users
  # Skip boost IF not get request OR uri has wrong dir OR cookie is set OR request came from this server OR https request
  RewriteCond %{REQUEST_METHOD} !^(GET|HEAD)$ [OR]
  RewriteCond %{REQUEST_URI} (^/(admin|cache|misc|modules|sites|system|openid|themes|node/add))|(/(comment/reply|edit|user|user/(login|password|register))$) [OR]
  RewriteCond %{HTTP_COOKIE} DRUPAL_UID [OR]
  RewriteCond %{HTTP:Pragma} no-cache [OR]
  RewriteCond %{HTTP:Cache-Control} no-cache [OR]
  RewriteCond %{HTTPS} on
  RewriteRule .* - [S=3]

  # GZIP
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=1]
  RewriteCond %{DOCUMENT_ROOT}/cache/gz/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz -s
  RewriteRule .* cache/gz/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html\.gz [L,T=text/html]

  # NORMAL
  RewriteCond %{DOCUMENT_ROOT}/cache/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html -s
  RewriteRule .* cache/%{SERVER_NAME}%{REQUEST_URI}_%{QUERY_STRING}\.html [L,T=text/html]

  ### BOOST END ###

Thank you so much for providing your settings. I'm using dev version.. so maybe this is why. I tried to use your settings, but it did not work for me. The only difference is that at the performance core settings you have normal cache enabled, and when one installs boost, it gets disabled, and that's how I have that setting (disabled) as in http://drupal.org/node/545908 "# Save the settings to install (updates the database)
After saving the settings, there will be a link at the top of the module page directing you to the (Performance/Boost settings) UI page.
After the module has been enabled, a notice will display
(Drupal's standard page caching disabled by Boost.). "
Not sure if I should enable that?
Well.. I tried, and it did not work.. still get a message:
"•CAPTCHA session reuse attack detected.
•The answer you entered for the CAPTCHA was not correct."
Other than that settings seems to be the same, yet it does not work. :(
Maybe someone else will figure out how you got this to work.. and how we can get it to work .

ALSO... the . file that gets generated in the dev version is different.. example does not have any :
"

Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"

"

I will see what I can find and meanwhile hopefully someone will shed some other light to this.
Not sure why it "expires in 1978"...;)

I looked at the settings in #28, set my Boost the same way but the CAPTCHA image refreshes only it's visual style, not the numbers user should put in. And since I am using version 6.x-1.18 of Boost and version 6.x-2.2 of CAPTCHA (the same as stated in #28), I have no idea how our settings differ.

I wish I know the solution, now I am scared to touch it so it won't break...;)
Do you think it might be something to do with the theme you are using? Try using a default theme.

If you need any other setting from my setup, please let me know.

Weird. I thought it was all clear. Now I'm totally confused.

So this morning I started testing again from the scratch:

1. Fresh Installation of drupal6.19 on my virtual dev-server:
   • Debian-lenny(9) x86
   • PHP 5.2.6-1
   • MySQL 5.0.51a
   • GDlib bundled (2.0.34 compatible)
2. Set $cookie_domain in settings.php
3. Activated optional core modules:
   • comment
   • contact
   • path
4. Installed contributed modules:
   • boost-6.x-1.18
   • devel-6.x-1.22 (including devel_generate-6.x-1.22)
   • http_request_fail_reset-6.x-1.0 (sorry for that one - i need it in dev)
   • global_redirect-6.x-1.2
   • pathauto-6.x-1.5
   • token-6.x-1.15
   • transliteration-6.x-3.0
   • capthcha-6.x-2.2 (including image_captcha-6.x-2.2)
5. Generated content with devel_generate
6. Activated the site-wide contact-form (Create main category, enable permissions, set unlimited submissions)
7. Allowed guests posting comments (permissions)
8. Removed "User login" block, created user login link.
9. Setup performance/boost settings (images attached)
10. Applied .htacces-code from boost. (textfile attached)
11. Activated "Boost: Pages cache status" block in sidebar
12. Activated image captcha for every form on every submission
13. Cleared all caches
14. Ran cron.php manually

So far no problems - and everything is up to date.
Then I began caching content through browsing and tested posting contact-messages and comment.
I also tested the following themes:

1. Garland (core-6.19)
2. Polpo-6.x-1.1
3. Zen-6.x-2.0

It quickly came clear...

• caching via boost is working in general
• captcha-images & codes keep cached and work cached
  • Good: it's working. Even with cached images/codes.
  • Bad: this results in way too long time spans where protection against ocr-scan-bots is not given.
• Only for "login", "new pw", and "register" image_captcha is workin as it should - of course it seems boost isn't caching paths like user/*

So as long this problem exists I suggest do not cache captcha-protected pages. Exclude them via the "Statically cache specific pages" textarea at boost settings (admin/settings/performance/boost).
Examples:

contact
comment/reply/*

Eventually there should be warnings around boost-/captcha-project pages and readme-files.

I'll keep on testing...

Thank you for the detailed explanation. I am baffled as why it is working for me in every section on my site, including comments. If you want, you can try my site at: www.keghart.com, enter comments under any article with the subject line: Testing for Vako. It's moderated and I can remove them later.
My settings are above, under#28.

I'm sorry to tell you BUT...

on that page I'm getting the same issue as we are all talking about:

When reloading the comment page without submitting the form
no new CAPTCHA is generated.

The image CAPTCHA shown is working - yes - as I described.
BUT without being newly generated on page reloads (F5).

I really don't like to say but that's a security issue.

Really weird is the fact that when such a form gets submitted
a new image captcha is generated and shown. But by reloading such a page
the system is falling back to the cached version with the captcha shown 2 steps before.
And the old captcha-code will be accepted again.

And I'm even more sorry to tell you BUT...
I cannot acces the comment-textarea on http://www.keghart.com/ when using opera.

Yes, as R2-D8 tested, I confirm. The Vako's site works exactly as mine does - that is a new image gets generated but with the same code on page reload. So no miracles seem to be taking place.

Guys, I don't see a problem here (except for the Opera browser).
yes F5 will generate the same graphic, however if you enter any comment, the CAPTCHA will change. Afterwards, on the same screen, CAPTCHA will generate new images each time you press F5. Try it please.
I don't see how a spammer will be able to penetrate in this scenario.

The problem is that on every first browser visit the captcha-code on your site is...

NZTHV

This has been the captcha-code on your site the whole day.
There is enough risk in this scenario for ocr-bots, maybe written by script-kiddies. After this discussion.

If this would only happen for moderated content like in your case we could be lame with that, but it's also affecting webforms and all that stuff.
Therefore a secure, unattended solution is needed.

And until that:
Please, don't cache image_captcha-protected pages with boost.

I understand it better now, thanks for the points. Also I noticed the following (correct me if I'm wrong):
- Each article's captcha is different
- After entering a comment the captcha image changes (maybe the cache is cleared) so a bot will only work once.
- After the Boost session is over, all captcha images change

In this case, if we change the setting of Boost to clear the cache every hour, then the same image will not be there anymore, am I right so far?

In my experience, I haven't gotten any bot attacks in the last 3 years with this site and Boost was installed about 15 months ago.

@Vako

1) Yes because every article has been cached individually with a unique timestamp. Timestamp is used to generate and identify captcha-solutions.
2) No: The image changes only for the user sending the comment; and when first leaving then coming back to the site with that "holy new image" the old image returns. And every other visitor/browser-cache will see the old (cached) image. So a bot could work as long as the page is cached.
3) Yes this comes to Point 1 again.

No Bots for years? Sounds like a dream to me. I struggle from week to week with crap like viagra-spam, extreme religious comments and so on... but that's another story.

I don't see any advantage in reducing caching-time-spans just to hide this "won't fix".
And I'm sure people seeing a not-working but accepted captcha won't trust in such a system again because it's against all their principals and understanding.

But as long as you are pre-moderating your captcha-protected contents you are on the safe side.
No matter what captcha-process you are using or not.

Hope I could bring up clearance - keep us informed

No Bots for years? Sounds like a dream to me.

I'm having great results using captcha and Bad Behavior module. I get about one spam form entry per week.

Well I can go for the nuclear option and detect that a captcha form is on the page and not cache it. Question is does captcha work with drupal's core page cache on a cache hit? If it does then in theory I should be able to make boost work with captcha.

I'm not sure; I thought I had this working with Boost caching anon pages (which works great and is very fast!), and with captcha. In all my content, I have the comment form right below the comments, which are below the content, with a captcha protecting the comment submission. It seemed to be working alright with Boost (I just set the captcha to always use 3 w's like WwW for every captcha).

But now I noticed that after some period of time, the Captcha no longer appears. If I copy the Captch image URL and put it into Firefox with live headers capture, sometimes it returns 404 not found for the image, and sometimes it returns 200 OK, but doesn't return any data (returns some cookie saying to set the DRUPAL_UID to 0). When I look in the Watchdog, I don't see any entries for Captcha. But at the same time, the Captcha sessions table is empty.

So I'm not sure what I will do about this. For the short term I may disable Boost until I can figure something else out. I'd really like to keep the comment submit right below the content.

I don't think it's the Boost. If you have noticed, Boost will disable itself on pages that has the CAPTCHA.
I have Boost and CAPTCHA and BOTCHA working together with no problem since 2007 and so far has captured about 40,000 spams.
I haven't had any issues. Yes, as indicated before, the CAPTCHA image on the page stays the same when you hit refresh, but once you submit it changes, so as far as I know it's working 100% correctly for me.
Please see my settings above and if they will help you in any way.

Yes, I agree, after looking into it, the issue does not appear to have anything to do with Boost. I have not noticed Boost excluding itself from pages that have Captchas though. I'm not sure specifically what happened to Captcha, but I noticed on some pages after a week or two, it will not return the Captcha image. It either returns 404 not found, or it returns 200 but returns no data (content-length is 0). Copying and pasting the Captcha image into a new browser window does the same thing. But when I look in the Captcha session database table, that Captcha is not present either. I don't see any related messages in the Web server logs or the watchdog table. So I'll have to dig a little deeper to see what is going on.

Ah ok, so I submitted a comment on the form where the image didn't show, using the correct captcha (since mine have three w's all the time), and it told me 'Captcha session reuse attack detected', told me the captcha was incorrect, then when the page reloaded it had a new captcha image that worked. I guess that's basically the topic of this thread.

Ah ha, I was looking in captcha.module and I now see where the Captcha sessions are going...they get deleted on cron runs if they are older than one day it appears. // remove challenges older than 1 day
db_query('DELETE FROM {captcha_sessions} WHERE timestamp < %d', time() - 60*60*24);

editing to add: Well in the end I decided to hack the Captcha and Captcha image modules for my site. Because of how Captcha uses the token (to allow the Captcha to be used at most once), it is not possible to use it on cached pages. The token is an excellent idea though to keep bots from reusing the same solved captcha over and over. I generated 40 captcha images, saved them numbers 1 to 40 dot .jpg, then put their solutions into a database table, and hacked the captcha code to use a random number 1-40 for the captcha_sid, then when a request comes in to verify a captcha, it looks it up in the database table to get the solution. So the same solution can be used over and over on a cached page. It's not the finest protection, but it allows me to cache pages with a captcha on them and I'll see how it works out against bots. All my content pages have the comment form below the content, so if i'm not going to cache pages with a captcha, I might as well just disable Boost entirely. But Boost is simply terrific at speeding up anonymous pages and lowering server load so I am not willing to turn it off.

@porcupine73:

After extended usage, I ran into the same problem with Captcha giving me that "attack detected" error and the missing images too. I gave up on Captcha and uninstalled it completely. Turns out the Bad Behavior module and a couple of Webform tricks I've done are holding their own against the bots just fine. I'm now Captcha free for over 30 days! ;-)

I may never go back, and people have stopped complaining about log-in troubles. :)

It was either Captcha or Boost, and Boost is mandatory on a big site on a VPS, so Captcha is gone.

Thanks for the info Gregarios. I think I will look into the bad behavior module too. I've done some testing on my captcha hacks and it appears to work now for anonymous users on pages cached by Boost. The 'attack detected' message appears to be if the same solved captcha is attempted to be used more than once, so I took that part out of the code.

It would seem many of the bots are programmed to recognize the most popular software such as Drupal, vBulletin, etc to be able to post spam. But if you apply your own tricks to make yours a little different than everyone elses, it seems to have a good chance of defeating the bots.

porcupine73,

You got it right, the CAPTCHA session has a duration of 1 day by default. If you use boost for 1 day or more then you run in the potential problem of getting a session out of date.

Several things to be noted here as I see that others have run in the problem. I still use CAPTCHA but know of those problems:

1) Session overlap -- if boost is to cache your pages 1 week, then the CAPTCHA session needs to be 1 week + 1 day (or more) to make sure that the CAPTCHA session does not go out of date too soon. If you cache your pages indefinitely with boost, then you should completely eliminate the DELETE of the CAPTCHA session:

db_query('DELETE FROM {captcha_sessions} WHERE timestamp < %d', time() - 60*60*24);

Change the timing by multiplying by the number of days: time() - 60*60*24*7, or comment out that line of code so sessions never expire.

2) Avoid caching -- as mentioned, you can add a path in the boost module settings, path that will never be cached; obviously, if all your pages have a caching problem, an easier solution would be to remove boost (or CAPTCHA)

3) Auto-reset the CAPTCHA on submission -- as mentioned by Vako, comments work just fine! That's because at the time you Save a comment, it resets the Boost cache of the corresponding node automatically. This means the next time you go to that page (even as anonymous) you get a new CAPTCHA session generated.

3.1) But that does not work on my site?! I read comments by 2 people saying that the CAPTCHA was still going out of date on some of their pages; it seems to me that would happen if the page is cached indefinitely... in that case, comment out the session DELETE of the CAPTCHA; it won't make any difference toward spammers since each CAPTCHA is still used only once; only problem is that if they attack you heavily, they will hit the page many times generating a DoS or equivalent.

4) Look into another solution such as "Spam" and "Bad behavior" to replace CAPTCHA

One more note as my case is still different from all of those raised here:

I create a page inside which I have an InsertNode (i.e. [node:123] tag). That inserted node is a webform that asks the user a question or two (i.e. email address, first name, etc.) Boost would know how to reset the webform properly, but in my case, it's totally non conventional since the InsertNode hides the webform.

Now what I'd like is to see a way to mark those pages as non-cached or somehow have a way to reset them on a Submit.

Is there an Action in the Rule package that could be used to clear a page from the Boost cache? That would be a good solution in my case. Any time Rules detects that a submission arrived, it would tell Boost to reset pages X, Y, Z...

Thank you.
Alexis Wilke

Drupal has to supply a "subscribe" button/funtionality to posts without us having to type the word and spam good conversations with the word "subscribe".
*rolling my f**ng eyes*

Drupal has to supply a "subscribe" button/funtionality to posts without us having to type the word and spam good conversations with the word "subscribe".

I agree, if for no other reason than to not have to view your profanity.

I agree, if for no other reason than to not have to view your profanity.

greg.. lmao...laughing my ass out!! HA!

I use the following modules together and have absolutely no problem whatsoever:
- CAPTCHA
- BOTCHA
- captcha_counter (optional - just to see 'captured' submissions)

Since 2007 this module has captured 46,530 attempts! see the attached image.

I switched to Mollom, and have no problem using it with Boost :)

I use webform and captcha. Users can make new webforms, I have to add manually the captcha as admin and if I have not done it for a while I may forgot to add the page into boost exceptions, which results in almost unusable forms !! If pages with captcha were automatically excluded from boost as they are from internal drupal cache, that would be a big improvement.

Use Recaptcha module along with the captcha and boost module. This works fine for me...

The module boost_captcha will allow boost caching of forms with captcha without worrying about captcha session expiry.

Can this support request be considered fixed?

I am marking this as outdated. I hope that is alright.