Project

General

Profile

Actions

Bug #3656

closed

Using captcha while not logged in and displayed multiple times on same page always fails

Added by krileon over 11 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
17 August 2012
Due date:
% Done:

100%

Estimated time:

Description

When using captcha while it is displayed more than once on the same page (profilebook and profilewall with anon posting) it results in the code always failing. This has no affect on users logged in however. Appears to be some sort of session issue in regards to matching captcha code. If only 1 captcha is displayed then it works fine.

https://www.joomlapolis.com/forum/153-professional-member-support/207764-captcha-issue?limit=6&start=6


Files

3656.patch (3.41 KB) 3656.patch krileon, 17 August 2012 17:38
Actions #1

Updated by krileon over 11 years ago

All instances of captcha on the same page have the same input name and same value, which seams fine (works when logged in; see GJ for example where up to 5 captchas would be on same page and works).

Actions #2

Updated by krileon over 11 years ago

For some strange reason it keeps re-generating the inputname and storing the new inputname to session. It also generates a second session entry. None of which contain the inputname sent with the post?? The session ID is sent with the POST to ensure it matches the correct session entry, but the inputname changed!

Actions #3

Updated by krileon over 11 years ago

It has no problems if there is only 1 captcha present. It also has no problems if the captcha that you use is the first rendered (profilebook instead of profilewall).

The issue appears to happen due to the POST simply posting back to profile and to its own tab. This means captcha re-renders during the post and re-generates its information and thus updating the session with a new inputname and captcha code.

Actions #4

Updated by krileon over 11 years ago

The first captcha rendered works because it handles the validation and storage before rendering. In the case of the second captcha the first captcha has already ran its rendering aspects, which changes the session information and thus breaking the validation. Maybe captcha shouldn't generate during a POST to prevent this? Alternative is to fix how profilebook handles its storage process (loop through and store before all display?).

Actions #5

Updated by krileon over 11 years ago

Both captchas render with the same session id, which is why the second captcha fails as by time the second captcah validates the information has already changed from the first captcha, which has the same session id.

Actions #6

Updated by beat over 11 years ago

a static variable kept for the validation purpose, and different from the newly rendered captcha should fix this imho ?

Actions #7

Updated by krileon over 11 years ago

Page reload occurs, which would purge the static var. It needs to be something session related.

Actions #8

Updated by krileon over 11 years ago

  • File 3656.patch 3656.patch added
  • Status changed from Assigned to Resolved
  • Assignee changed from krileon to beat
  • % Done changed from 0 to 100

Implemented caching of previous captcha input name and code. Confirmed working using profilebook, profilewall, and public email (3rd party); confirmed GJ captchas work fine; confirmed registration captcha works fine; confirmed login captcha works fine.

Actions #9

Updated by beat over 11 years ago

  • Assignee changed from beat to nant

Patch is ok for committing and releasing: Security review passed.

Actions #10

Updated by nant over 11 years ago

  • Status changed from Resolved to Feedback
  • Assignee changed from nant to beat

I am confused.

It looks like the patch submitted was based on the files found on the dev1 svn repository (plugins -> plug_captcha and not the code stored in the CB repository (which btw is in sync with what is released to advanced members).

Sending this back to Beat because I do not want to mess something up.

We need to finally have 1 version to remove confusion.

Actions #11

Updated by krileon over 11 years ago

  • Status changed from Feedback to Closed

CB SVN changes have been moved to DEV1 SVN.

Patch committed in r2561.

Actions

Also available in: Atom PDF