Subversion Repositories SmartDukaan

Last modification

• Rev 37552 – 30 d 13 h
• Author: amit

• Log message:

  lead/knowlarity: stop a null lookup key from matching every row
  
  selectByEquals maps a null VALUE to NO PREDICATE AT ALL rather than to "= null",
  because GenericRepositoryImpl.prepareEqualPredicate skips null entries. So a null
  lookup key does not miss -- it selects the whole table and dies on
  NonUniqueResultException. Two live call paths were doing exactly that.
  
  RecordingService.updateAgentCallLog read caller_id, which knowlarity has never sent
  on push-call-log: a sample of 50 live webhooks contained it zero times. Every call
  therefore ran selectByCallerId(null) -> "select every sip_master row" -> throw, and
  the whole feed was discarded. 17 of those 50 were Connected calls with a real agent.
  Resolve the agent from agent_number instead, which is the field that actually
  identifies them and holds the sip_url; it arrives bare, sip:-prefixed, or as the
  literals "False"/"None" when nobody picked up. caller_id is still honoured first in
  case they ever start sending it. A payload naming no agent is INFO, and an agent
  missing from sip_master is WARN (an ops fix, and per-agent, so an ERROR would
  fingerprint into one GlitchTip issue per agent).
  
  AuthRepositoryImpl.putEmailOrMobile had the same hole via Long.parseLong(null)
  falling into the catch and putting a null email. selectByEmailOrMobile(null)
  degenerated to "select all 405 users", and authenticate(null, hash) degenerated to
  "does ANY user have this password hash", which would answer true. Both fail closed
  today only as an accident of how many rows the table holds, so the guard goes on the
  one path they share.
  
  Fixes GlitchTip #58/#1324/#1335 (fofo, 281 events) and #10 (web).