Kallithea issues archive

Issue #334: Add Repo Permission for user with user_id contains only digits

Reported by: Mathias He
State: closed
Created on: 2019-03-08 10:15
Updated on: 2020-06-18 20:09



we are working with version 0.3.2 and have a problem to give a user write permission on a repository. His user id contains only digits (e.g. 7375). It looks like, that there is an error with number to string function.

He is able to login with his account.

Error Log:

Module kallithea.controllers.admin.repos:373 in edit_permissions_update
>>  Session().commit()
Module sqlalchemy.orm.session:710 in commit
>>  self.transaction.commit()
Module sqlalchemy.orm.session:368 in commit
>>  self._prepare_impl()
Module sqlalchemy.orm.session:347 in _prepare_impl
>>  self.session.flush()
Module sqlalchemy.orm.session:1734 in flush
>>  self._flush(objects)
Module sqlalchemy.orm.session:1805 in _flush
>>  flush_context.execute()
Module sqlalchemy.orm.unitofwork:331 in execute
>>  rec.execute(self)
Module sqlalchemy.orm.unitofwork:475 in execute
>>  uow
Module sqlalchemy.orm.persistence:64 in save_obj
>>  table, insert)
Module sqlalchemy.orm.persistence:558 in _emit_insert_statements
>>  execute(statement, params)
Module sqlalchemy.engine.base:1449 in execute
>>  params)
Module sqlalchemy.engine.base:1584 in _execute_clauseelement
>>  compiled_sql, distilled_params
Module sqlalchemy.engine.base:1698 in _execute_context
>>  context)
Module sqlalchemy.engine.base:1691 in _execute_context
>>  context)
Module sqlalchemy.engine.default:331 in do_execute
>>  cursor.execute(statement, parameters)
IntegrityError: (IntegrityError) null value in column "user_id" violates not-null constraint DETAIL: Failing row contains (200, null, 3, 112). 'INSERT INTO repo_to_perm (user_id, permission_id, repository_id) VALUES (%(user_id)s, %(permission_id)s, %(repository_id)s) RETURNING repo_to_perm.repo_to_perm_id' {'repository_id': 112, 'permission_id': 3, 'user_id': None}
CGI Variables
CONTENT_TYPE    'application/x-www-form-urlencoded; charset="utf-8"'
CONTEXT_DOCUMENT_ROOT   '/opt/kallithea/html'
DOCUMENT_ROOT   '/opt/kallithea/html'
HTTP_ACCEPT 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8'
HTTP_ACCEPT_ENCODING    'gzip, deflate'
HTTP_ACCEPT_LANGUAGE    'de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7'
HTTP_COOKIE 'kallithea=9fcf2dfc217b22b9982d5faf0468c8fddffbc1aa9f8e4af7393248baa38dfd86aa5b592d'
HTTP_HOST   'server.name'
HTTP_ORIGIN 'http://server.name'
HTTP_REFERER    'http://server.name/repo.name/settings/permissions'
HTTP_USER_AGENT 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36'
HTTP_VIA    '1.1 server.name'
HTTP_X_FORWARDED_HOST   'server.name'
PATH_INFO   '/repo.name/settings/permissions'
PATH_TRANSLATED '/opt/kallithea/dispatch.wsgi/repo.name/settings/permissions'
REQUEST_URI '/repo.name/settings/permissions'
SCRIPT_FILENAME '/opt/kallithea/dispatch.wsgi'
SERVER_ADMIN    '[no address given]'
SERVER_NAME 'server.name'
SERVER_SIGNATURE    '<address>Apache/2.4.10 (Debian) Server at server.name Port 80</address>\n'
SERVER_SOFTWARE 'Apache/2.4.10 (Debian)'
WSGI Variables
apache.version  (2, 4, 10)
application <kallithea.lib.middleware.sessionmiddleware.SecureSessionMiddleware object at 0x7f97cba59590>
beaker.get_session  <bound method SecureSessionMiddleware._get_session of <kallithea.lib.middleware.sessionmiddleware.SecureSessionMiddleware object at 0x7f97cba59590>>
beaker.session  {'_authentication_token': '203281082906200313906986857299832736540', 'authuser': {'is_authenticated': True, 'is_external_auth': False, 'user_id': 2}, '_accessed_time': 1551972691.364228, '_creation_time': 1551972566.802168}
mod_wsgi.application_group  '|'
mod_wsgi.callable_object    'application'
mod_wsgi.enable_sendfile    '0'
mod_wsgi.handler_script ''
mod_wsgi.input_chunked  '0'
mod_wsgi.listener_host  ''
mod_wsgi.listener_port  '80'
mod_wsgi.process_group  ''
mod_wsgi.request_handler    'wsgi-script'
mod_wsgi.request_start  '1551972691349599'
mod_wsgi.script_reloading   '1'
mod_wsgi.script_start   '1551972691350112'
mod_wsgi.version    (4, 3, 0)
paste.registry  <paste.registry.Registry object at 0x7f97c92c27d0>
paste.throw_errors  True
pylons.action_method    <bound method ReposController.edit_permissions_update of <kallithea.controllers.admin.repos.ReposController object at 0x7f97c8fdf150>>
pylons.controller   <kallithea.controllers.admin.repos.ReposController object at 0x7f97c8fdf150>
pylons.environ_config   {'session': 'beaker.session', 'cache': 'beaker.cache'}
pylons.log_debug    True
pylons.pylons   <pylons.util.PylonsContext object at 0x7f97c9369f10>
pylons.routes_dict  {'action': u'edit_permissions_update', 'controller': u'admin/repos', 'repo_name': u'repo.name'}
routes.route    <routes.route.Route object at 0x7f97ce7aaf50>
routes.url  <routes.util.URLGenerator object at 0x7f97c92c2710>
webob._body_file    (<LimitedLengthFile(<cStringIO.StringI object at 0x7f97c9350f10>, maxlen=334)>, <cStringIO.StringI object at 0x7f97c9350f10>)
webob._parsed_post_vars (MultiDict([('_method', 'put'), ('_authentication_token', '203281082906200313906986857299832736540'), ('repo_private', 'False'), ('u_perm_default', 'repository.write'), ('u_perm_htm', 'repository.write'), ('perm_new_member_1', 'repository.read'), ('perm_new_member_name_1', '7375'), ('perm_new_member_type_1', 'user'), ('perm_new_member_2', 'repository.read'), ('perm_new_member_name_2', ''), ('perm_new_member_type_2', ''), ('save', 'Save')]), <FakeCGIBody at 0x7f97c92c23d0 viewing MultiDict([('_m...e')])>)
webob._parsed_query_vars    (GET([]), '')
webob.adhoc_attrs   {'errors': 'ignore'}
webob.is_body_readable  True
webob.is_body_seekable  False
wsgi process    'Multi process AND threads (?)'
wsgi.file_wrapper   <type 'mod_wsgi.FileWrapper'>
wsgiorg.routing_args    (<routes.util.URLGenerator object at 0x7f97c92c2710>, {'action': u'edit_permissions_update', 'controller': u'admin/repos', 'repo_name': u'repo.name'})



Comment by Mads Kiilerich, on 2019-03-08 11:39

It is an old and deep assumption in the code base that usernames not are digits. There are layers where users are identified either by number or by name, and I expect it to be confused if the name is a number.

I think the main problem here is that the user got that far. It should probably have been rejected early with an error message.

I don't know if we can/will fix the design to support your use case, but it still sounds confusing to have user names that are pure numbers. I suggest prefixing names with a letter.

Comment by Mathias He, on 2019-03-11 15:48


i can't change the usernames with a prefix, as it is the design of our company and I only read the LDAP information. The account could be created on first login, so there were no problem with the number as username.

Why it is such a problem to use the str() function on the username? This shouldn't be a big problem.

best regards,