[Koha-bugs] [Bug 12371] Links in every patron self-registration email points to a single borrower

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12371

--- Comment #8 from Kyle M Hall <kyle at bywatersolutions.com> ---
While I agree your solution would work, I think this one is better because it
solves it at the root of the problem. Fixing the issue at the
opacmemberentry.pl level would make it easier to introduce regressions in the
future. Thanks for the input though!

(In reply to Nick Clemens from comment #7)
> It is possible I am wrong, but I couldn't recreate the problem in testing.
> 
> Looking at the code that dmin mentions it appears that opac-memberentry.pl
> passes two variables to the sql query in Letters.pm
> 
> It appears that the function in Letters.pm was designed to allow for general
> use in pulling from 'borrower_modifications' using either borrowernumber or
> verification_token.
> 
> When trying to pull data by verification_token, opacmemberentry.pl passes
> the verification_token for both variables (borrowernumber compare and
> verification_token compare)
> 
> In my testing, when mysql gets a string as a variable to compare to an
> integer (borrowernumber) it will just take the first integer and chop the
> rest of the string, meaning any verification_token that beings with zero
> will compare successfully to borrowernumber zero
> 
> It should be possible to leave the original sql in Letters.pm and just
> replace the first variable passed from opacmemberentry.pl  from
> verification_token to 'a' to prevent matching to zero and to force a
> comparison of the tokens.

-- 
You are receiving this mail because:
You are watching all bug changes.