• Resolved bmogged

    (@bmogged)


    Hello,

    Used this program for the last year and so far had only a few issues. But the 1.2 version threw our users into a loop.

    The problem is that you can enter a race condition with the registration form – let me explain.

    User a goes to the form to fill it out. It generates the value and uses the set_transient function to save the values.
    User b (bot, search engine, or real user) goes to the page. It regenerates the values and saves them to the options.
    User a hits save and it compares to user b options. It now resets it for both User a and b.

    So I had some user complaints about trying to register 4-6 times and it not working. I couldn’t reproduce the problem in dev until I looked at the code.

    — Thoughts —

    There needs to be some way to make the information unique per user not one value for the whole site.

    Right off top of my head if still want to use transients it might be better to place a hidden input field with a GUID on the page and use something like set_transient with the guid as part of the key. The page would need to have nocache on the page so that it’s not have any chance of given to another user. But also to consider – since transients are not cleared even if they are expired unless you call them again this might gunk up the database. So still not ideal so that’s what I didn’t do.

    On my version of the code since I have sessions being used on the site already I replaced the transient calls with session and that solves the problem on my end.

    Since I know most people don’t use or want to use sessions I didn’t upload the changes.

    https://wordpress.org/plugins/bp-security-check/

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Shea Bunge

    (@bungeshea)

    Interesting. I knew that the transistant method was not perfect, but it was the best I could come up with, as using only hidden fields were proving to be too easy for bots to crack.

    Perhaps, as you suggest, a mix of hidden fields and the database could be a solution. To prevent the orphaned transistent problem, perhaps all of the sum information could be saved in a single option as an array keyed by the GUID. This option could then be cleared by cron every 6 hours or something.

    Does this sound viable to you?

    Plugin Author Shea Bunge

    (@bungeshea)

    I’ve just released version 1.3.0 which includes a fix for this issue. What I’m doing now is appending a unique ID to transient name, and storing that ID in a hidden form field. When it comes to verifying the question, the ID is pulled from the submitted form data and used to fetch the question information from the database. Hopefully this should fix this issue; please test it out and let me know if it works. Thanks!

    Plugin Author Shea Bunge

    (@bungeshea)

    Also, thanks very much for noticing this issue and providing such a detailed report.

    Unfortunately it keeps returning the same math error. Randomly some of the answers are stated as wrong. I’m right now taking turns on my BP registration page and making test users registrations and sometimes it fails.

    Obviously I’m using v 1.3.0

    You should check it all over again.

    Looks like it stopped return errors. If it comes with more errors I’ll let you know.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Race Condition in 1.2 version of the plug in’ is closed to new replies.