User and password for syncing overwritten when running with --sync-server

Bug #1644402 reported by Kienan
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
The Mnemosyne Project
Fix Released
Undecided
Unassigned

Bug Description

Using mnemosyne 2.3.6 in a headless environment, I set the user/password in the following manner:

$> cd /path/to/mnemosyne-data-directory
$> python
>>> import sqlite3
>>> conn = sqlite3.connect('config.db')
>>> c = conn.cursor()
>>> print c.execute('select * from config where key like "%remote%"').fetchall()
[(u'remote_access_username', u"''"), (u'remote_access_password', u"''")]
>>> c.execute('update config set value = "YOUR PASSWORD" where key = "remote_access_password"')
<sqlite3.Cursor object at 0x7f6bc9916ab0>
>>> c.execute('update config set value = "YOUR USERNAME" where key = "remote_access_username"')
<sqlite3.Cursor object at 0x7f6bc9916ab0>
>>> conn.commit()
>>> conn.close()
>>> # just an extra check to see the file was written.
>>> conn = sqlite3.connect('config.db')
>>> c = conn.cursor()
>>> print c.execute('select * from config where key like "%remote%"').fetchall()
[(u'remote_access_username', u'YOUR USERNAME'), (u'remote_access_password', u'YOUR PASSWORD')]
>>> conn.close()

When I start mnemosyne (mnemosyne -d /path/to/mnemosyne-data-directory and try to connect a client, using the username and password set fails. When inspecting the keys set in the sqlite db, they have returned to empty strings. Syncing a client with an empty username and password works as expected.

Revision history for this message
Peter Bienstman (peter-bienstman) wrote :

I cannot reproduce this when editing config.db manually with sqlite browser. After starting and stopping the headless server, the username and password are still in the config file, and syncing with those values works. Are you sure you're not confusing directories/files?

Changed in mnemosyne-proj:
status: New → Incomplete
Revision history for this message
Kienan (viashimo) wrote :

Yup, there's only one config.db on the headless machine I'm using.

mnemosyne@x:~$ find . -iname "config.db"
./mnemosyne-data/config.db
mnemosyne@x:~$

I just tried with mnemosyne 2.4 and following the previous steps I get the exact same behaviour. Once mnemosyne is restarted those two values are wiped from the config table in config.db

Revision history for this message
Kienan (viashimo) wrote :

This is ho I start the syncserver:

mnemosyne@x:~/mnemosyne-data$ mnemosyne -d /home/mnemosyne/mnemosyne-data/ --sync-server /home/mnemosyne/mnemosyne-data/default.db &

Revision history for this message
Peter Bienstman (peter-bienstman) wrote :

I'll put this on my todo list to try again to reproduce.

However, I never start the sync server by listing the database name, so just:

mnemosyne -d /home/mnemosyne/mnemosyne-data/ --sync-server &

Not sure if that'll make a difference, though.

Changed in mnemosyne-proj:
status: Incomplete → New
Revision history for this message
Kienan (viashimo) wrote :

I tried without listing the database name, no change. I'll try to have a closer look at some point too.

Revision history for this message
Peter Bienstman (peter-bienstman) wrote :

This might be due to a race condition with access to the config database. This version should be more thread-safe: https://www.dropbox.com/s/nc5g9wq9bxaz1mx/Mnemosyne-2.4.tar.gz?dl=0

Can you check if this solves your problem?

Changed in mnemosyne-proj:
status: New → Incomplete
Revision history for this message
Peter Bienstman (peter-bienstman) wrote :

I'm assuming this is fixed in 2.4.1, but if not, do reopen.

Changed in mnemosyne-proj:
status: Incomplete → Fix Released
Revision history for this message
Kienan (viashimo) wrote :

Still happening in 2.4.1 at dl'd from the project page.

Revision history for this message
Peter Bienstman (peter-bienstman) wrote :

I think I figured out what's going on here: you should not store a string in the database, but rather repr(string). I.e. compare the difference between

In [6]: a = "foo"
In [7]: print(a)
foo
In [8]: print(repr(a))
'foo'

So, you're missing some quotes.

Revision history for this message
Kienan (viashimo) wrote :

Hah yeah, that did the trick. Thanks!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.