---- Reported by jwagner@ptfs.com 2010-02-25 18:58:43 ---- I'm not sure if this is a bug or a feature. It's one of the options discussed in http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3280 for improving cart email security. In 3.0.x, the OPAC cart could be emailed by any user. At current head, the cart forces the user to log into the OPAC before it will email the contents of the cart. Is this intentional? Is it desirable? ---- Additional Comments From jwagner@ptfs.com 2010-02-25 19:13:31 ---- See http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3651 which seems to have set this. I think it should be configurable, so that libraries could use a syspref to turn it on/off. Is there any way to do it so that users don't have to log in to send a cart but security is preserved? ---- Additional Comments From jwagner@ptfs.com 2010-02-25 19:20:16 ---- Also see http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3280 about cart security. --- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:25 UTC --- This bug was previously known as _bug_ 4274 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4274 Unknown operating system Windows 2000. Setting to default OS "All". Actual time not defined. Setting to 0.0 The original reporter of this bug does not have an account here. Reassigning to the person who moved it here: chris@bigballofwax.co.nz. Previous reporter was jwagner@ptfs.com. Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
I would also like to see this changed, so that users do not have to be logged in to use the cart/e-mail feature.
We could implement a CAPTCHA for this
I personally don't think we should require login to mail a cart. What if I'm in the library at a public terminal and want to email a list of titles to myself, making me log in means I have to remember to log out of the public computer. Also Captcha is not accessibility friendly.
My comments on Bug 7383 might be more appropriate here: Basically, I agreeing that the e-mail cart feature is quite useful as a standard saving feature, and to require login is too restrictive for: 1) reference-only libraries that don't circulate and don't require user accounts. 2) researchers using a special library's catalog at another location and does not have a user account. It would be great if we can figure out a solution so that it's easier for users to e-mail citations to themselves for later research.
Hi, I'd like to chime in that requiring a username and password in order to email cart contents is not an improvement in our eyes. We have a lot of school libraries as members of our shared system. They don't necessarily want their students to have usernames and passwords to access the system, but they would like to be able to have the kids email contents of carts either to the staff librarian so they can place holds on behalf of the students or so that students can do research and email the results of that search to themselves to use later. Having this access now blocked by a username and password is not good. I'd like it to be restored to what it was before or at the very least have username and password access to cart contents be a on/off switch in the system administration. Thanks, Nora Blake MassCat
(In reply to comment #5) > Hi, > > I'd like to chime in that requiring a username and password in order to email > cart contents is not an improvement in our eyes. We have a lot of school > libraries as members of our shared system. They don't necessarily want their > students to have usernames and passwords to access the system, but they would > like to be able to have the kids email contents of carts either to the staff > librarian so they can place holds on behalf of the students or so that students > can do research and email the results of that search to themselves to use > later. > > Having this access now blocked by a username and password is not good. I'd > like it to be restored to what it was before or at the very least have username > and password access to cart contents be a on/off switch in the system > administration. > What it was before was needing login, then that got broken by accident with the opacpublic changes, then it was restored. The main reason being, it's a spam tool otherwise, so before we can let it be used without a login, someone needs to propose a solution that will stop spammers using it, that isn't using captcha or another discriminatory technique. Then we are good to go with a syspref.
(In reply to Chris Cormack from comment #6) > (In reply to comment #5) > The main reason being, it's a spam tool otherwise, so before we can let it > be used without a login, someone needs to propose a solution that will stop > spammers using it, that isn't using captcha or another discriminatory > technique. Then we are good to go with a syspref. Perhaps a negative captcha like we're now using for the Anonymous Suggestions as per bug 3144? I included some links on Comment 24 with some information. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3144#c24
A human being might still misuse the feature - I think it should be a choice for the library, so they can turn off 'non logged in cart sending'.
(In reply to Katrin Fischer from comment #8) > A human being might still misuse the feature - I think it should be a choice > for the library, so they can turn off 'non logged in cart sending'. Agreed. We actually have this implemented locally as an "anonymous cart" system preference. I think most of our libraries have it turned off (ie require login), but a few want anyone to be able to use the cart.
(In reply to David Cook from comment #9) > (In reply to Katrin Fischer from comment #8) > > A human being might still misuse the feature - I think it should be a choice > > for the library, so they can turn off 'non logged in cart sending'. > > Agreed. We actually have this implemented locally as an "anonymous cart" > system preference. I think most of our libraries have it turned off (ie > require login), but a few want anyone to be able to use the cart. Still have the code somewhere?
(In reply to Jonathan Druart from comment #10) > (In reply to David Cook from comment #9) > > (In reply to Katrin Fischer from comment #8) > > > A human being might still misuse the feature - I think it should be a choice > > > for the library, so they can turn off 'non logged in cart sending'. > > > > Agreed. We actually have this implemented locally as an "anonymous cart" > > system preference. I think most of our libraries have it turned off (ie > > require login), but a few want anyone to be able to use the cart. > > Still have the code somewhere? Yes, although we've customized the cart quite a bit, so it would take time, which I don't have, to unravel it enough to share. Basically, I think you have a system preference, and enable $authnotrequired where necessary and add Koha.Preference( '<anonymous cart>' ) where necessary in the templates. I could look at this another time, but need to focus on other things atm.
Chiming in that I'm currently training a library that doesn't have patron records and therefore doesn't allow opac login but would like to be able to email the cart. So it'd be great to see this move forward. Thanks!
(In reply to Andrew Fuerste-Henry from comment #12) > Chiming in that I'm currently training a library that doesn't have patron > records and therefore doesn't allow opac login but would like to be able to > email the cart. So it'd be great to see this move forward. Thanks! Unfortunately, I'm swamped with other work, so it's not on my list of priorities.
David, any chance you could push the branch you've got this code in somewhere public, so we could do the work of pulling this feature out for you? Seems a pity to have to re-engineer it. Cheers, Liz
*** Bug 24579 has been marked as a duplicate of this bug. ***
I am not sure if this is a feature that we should implement given the possible security/spam implications. A bot or human misusing the feature could get the library's email address blacklisted for example. Would someone else support a CLOSED WONTFIX?
(In reply to Katrin Fischer from comment #16) > I am not sure if this is a feature that we should implement given the > possible security/spam implications. A bot or human misusing the feature > could get the library's email address blacklisted for example. > > Would someone else support a CLOSED WONTFIX? Yes, we should close it.