can just keep antispam = utils.AntiSpam() in AntiSpamTestApppost instead of making an __init__
with audits('Honeypot login' doesn't pair up with any actual audit log. I think the ValueError is being raised so with with audits doesn't have a chance to check. So just remove that line I guess
if the login overlay is used (e.g. /p/add_project) then the CSS to hide honeypot fields isn't working. see login_fragment.html
I noticed that as long as you have a valid spinner & timestamp, you can submit the form with "regular" field names, e.g. username & password instead of the encoded names. I think this is a general limitation of how the AntiSpam class is set up right now since it updates the params dict instead of making a new one. We could explore the idea of deleting all other params. But that might have some adverse affects if we have a non-encoded param like return_to (would have to make sure everything is encoded on all antispam forms)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
QA
branch
kt/antispam_loginif g.antispamprobably doesn't need to be checked# ahh i'm dead hereantispam = utils.AntiSpam()inAntiSpamTestApppostinstead of making an__init__with audits('Honeypot login'doesn't pair up with any actual audit log. I think theValueErroris being raised so withwith auditsdoesn't have a chance to check. So just remove that line I guesslogin_fragment.htmlI noticed that as long as you have a valid spinner & timestamp, you can submit the form with "regular" field names, e.g. username & password instead of the encoded names. I think this is a general limitation of how the AntiSpam class is set up right now since it updates the params dict instead of making a new one. We could explore the idea of deleting all other params. But that might have some adverse affects if we have a non-encoded param like return_to (would have to make sure everything is encoded on all antispam forms)
Good feedback; fixups pushed.