credativ team mailing list archive

[Launchpad Bug Tracker <862306@xxxxxxxxxxxxxxxxxx>]

[Expired for OpenERP Server because there has been no activity for 60
days.]

** Changed in: openobject-server
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of OpenERP
Framework Experts, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/862306

Title:
  res_users rowlock - admin cant login

Status in OpenERP Server:
  Expired

Bug description:
  Admin user cannot login (by that, I mean the call to the login
  function performed by the web-client) during the call of a long
  function.

  This bug was identified on 6.0 (rev 3492) but can certainly be
  reproduced on trunk.

  To reproduce:
  - install a fresh database with demo data (with admin pwd set to 'admin')
  - install the 'login_test' module provided in attachment (it provides a infinite loop test function that performs write's call on object res.widget.user + a monkey patch fixing the problem)
  - launch 2 python consoles:

  ###############################################################
  ###############################################################
  # Preparation:

  # Shell 1:
  dbname = 'test_login'
  uid = 1
  pwd = 'admin'
  import xmlrpclib
  sock = xmlrpclib.ServerProxy('http://localhost:8069/xmlrpc/object')
  sock_common = xmlrpclib.ServerProxy('http://localhost:8069/xmlrpc/common')

  sock_common.login(dbname, 'admin', pwd)

  demo_id = sock_common.login(dbname, 'demo', 'demo')
  demo_id2 = sock.execute(dbname, uid, pwd, 'res.users', 'copy', demo_id)
  sock.execute(dbname, uid, pwd, 'res.users', 'write', demo_id2, {'login': 'demo2'})
  demo_id2 = sock_common.login(dbname, 'demo2', 'demo')
  ###############################################################
  # Shell 2:
  sock_common = xmlrpclib.ServerProxy('http://localhost:8069/xmlrpc/common')

  
  ###############################################################
  ###############################################################
  # TEST 1: 
  # run in Shell 1
  sock.execute(dbname, uid, pwd, 'res.company', 'test')
  ###############################################################
  # run in Shell 2:
  sock_common.login(dbname, 'demo', 'demo')
  # => OK
  sock_common.login(dbname, 'demo2', 'demo')
  # => OK
  sock_common.login(dbname, 'admin', pwd)
  # => Not OK
  # select * from pg_stat_activity in postgres returns a waiting request: "UPDATE res_users SET date=now() WHERE login=E'admin' AND password=E'admin' AND active RETURNING id"

  ###############################################################
  ###############################################################
  # restart OpenERP server to get rid of waiting requests
  # TEST 2: 
  # run in Shell 1
  sock.execute(dbname, demo_id, 'demo', 'res.company', 'test')
  ###############################################################
  # run in Shell 2:
  sock_common.login(dbname, 'demo2', 'demo')
  # => OK
  sock_common.login(dbname, 'demo', 'demo')
  # => Not OK
  # select * from pg_stat_activity in postgres returns a waiting request: "UPDATE res_users SET date=now() WHERE login=E'demo' AND password=E'demo' AND active RETURNING id"

  ###############################################################
  ###############################################################
  # restart OpenERP server to get rid of waiting requests
  # TEST 3: 
  # run in Shell 1
  sock.execute(dbname, demo_id, 'demo', 'res.company', 'test')
  ###############################################################
  # run in Shell 2:
  sock_common.login(dbname, 'demo2', 'demo')
  # => OK
  sock_common.login(dbname, 'admin', pwd)
  # => Not OK
  # select * from pg_stat_activity in postgres returns a waiting request: "UPDATE res_users SET date=now() WHERE login=E'admin' AND password=E'admin' AND active RETURNING id"

  
  So Test 1&2 show you cannot login as user X while your user X is already performing a long call in OpenERP (so why not, it could make sense...).
  But Test 3 proves you cannot login as the admin while an other user is performing a long call (which is more problematic).

  The problem comes from the login function of res.users which performs
  a (n useless) update on its row to update its last connection time.

  Replacing UPDATE res_users SET date=now() WHERE login=%s AND password=%s AND active RETURNING id
  by SELECT id FROM res_users WHERE login=%s AND password=%s AND active
  makes the trick
  Just uncomment line 57 of the __init__.py file of my module to test.

  
  The best would probably to get rid of this date update at login (and of the 'date' field on res_users). Maybe develop an ad-hoc module to log every user connection...

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/862306/+subscriptions