Email binding is not being stored

[mrjohnson22]

Reproduction steps:

• In Riot/Web, I had already used Settings->Email Addresses to add two email addresses to my Matrix account (this part is handled by Synapse). I know this worked properly because I am able to log into my account by providing my email address instead of my mxid.
• Under Settings->Discovery->Email addresses, I click "Share" next to an email address. POST _matrix/identity/v2/validate/email/requestToken gets a numeric sid as a response.
• ma1sd correctly sends an email to the account I wanted to share. Clicking the token contained in the email says "verification successful".
• Back in Riot/Web, clicking "Complete" has it turn into a "Revoke" button, suggesting that the binding worked. GET _matrix/identity/v2/account responds with my user_id.
• Trying to do the same thing with a different email address, but without clicking on the token link sent by ma1sd, fails. This means that ma1sd is handling verification correctly.

The problem: Closing & reopening the Settings window still has the "Share" button next to the email address that should have been shared already. POST _matrix/identity/v2/lookup responds with an empty mappings object.

Expected results: The lookup of my just-shared email should succeed.

Other info:

• The accepted and hashes tables in ma1sd's database are empty, but account is not.

• My (partially redacted) config:

  
  matrix:
  domain: 'domain'
  v1: true
  v2: true
  ## Remove default matrix-org server
  identity:
  servers:
    myOtherServers: []

server: name: 'identity.domain'

key: path: '/var/lib/ma1sd/keys'

storage: backend: postgresql provider: postgresql: database: '//localhost/ma1sd' username: 'user' password: 'pass'

synapseSql: enabled: true type: 'postgresql' connection: '//localhost/synapse?user=synapse_user&password=pass'

threepid: medium: email: identity: from: "noreply-id@domain" name: "Name" connectors: smtp: host: "localhost" tls: 0 port: 25

hashing: enabled: true pepperLength: 20 rotationPolicy: per_requests hashStorageType: sql algorithms:

• sha256 delay: 2m requests: 10

synapseSql: lookup: query: 'select user_id as mxid, medium, address from user_threepids' legacyRoomNames: false

logging: root: debug app: debug

Note that using the `none` algorithm (before or after `sha256`) doesn't fix the problem, and neither does changing `hashStorageType` to `in_memory`.

* Log contents (partially redacted) for when a binding is attempted:

INFO io.kamax.mxisd.auth.AccountManager - Found account for user: @mxid:domain INFO io.kamax.mxisd.http.undertow.handler.auth.v2.AccountGetUserInfoHandler - Get User Info. INFO io.kamax.mxisd.http.undertow.handler.auth.v2.AccountGetUserInfoHandler - Account found: @mxid:domain INFO io.kamax.mxisd.auth.AccountManager - Found account for user: @mxid:domain INFO io.kamax.mxisd.session.SessionManager - Server 127.0.0.1 is asking to create session for io.kamax.matrix.ThreePid@deadbeef (Attempt #1) - Next link: null INFO io.kamax.mxisd.session.SessionManager - No existing session for io.kamax.matrix.ThreePid@deadbeef INFO io.kamax.mxisd.session.SessionManager - Generated new session 1234567891234 to validate io.kamax.matrix.ThreePid@deadbeef from server 127.0.0.1 INFO io.kamax.mxisd.session.SessionManager - Stored session 1234567891234 INFO io.kamax.mxisd.session.SessionManager - Session 1234567891234 for io.kamax.matrix.ThreePid@deadbeef: sending validation notification INFO io.kamax.mxisd.threepid.generator.GenericTemplateNotificationGenerator - Generating notification content for 3PID Session validation INFO io.kamax.mxisd.threepid.connector.email.EmailSmtpConnector - Sending email to email@domain via SMTP using localhost:25 INFO io.kamax.mxisd.threepid.connector.email.EmailSmtpConnector - Connecting to localhost:25 INFO io.kamax.mxisd.threepid.connector.email.EmailSmtpConnector - Not using SMTP authentication INFO io.kamax.mxisd.threepid.connector.email.EmailSmtpConnector - Email to email@domain was sent INFO io.kamax.mxisd.http.undertow.handler.identity.share.SessionValidationGetHandler - Handling GET request to validate session INFO io.kamax.mxisd.session.SessionManager - Validating session 1234567891234 INFO io.kamax.mxisd.session.SessionManager - Session 1234567891234 is from 127.0.0.1 INFO io.kamax.mxisd.session.SessionManager - Session 1234567891234 has been validated INFO io.kamax.mxisd.http.undertow.handler.identity.share.SessionValidationGetHandler - Session 1234567891234 was validated INFO io.kamax.mxisd.auth.AccountManager - Found account for user: @mxid:domain INFO io.kamax.mxisd.http.undertow.handler.auth.v2.AccountGetUserInfoHandler - Get User Info. INFO io.kamax.mxisd.http.undertow.handler.auth.v2.AccountGetUserInfoHandler - Account found: @mxid:domain INFO io.kamax.mxisd.auth.AccountManager - Found account for user: @mxid:domain INFO io.kamax.mxisd.session.SessionManager - Session 1234567891234: Binding of email:email@domain to Matrix ID @gxid:domain is accepted

[ma1uta]

ma1sd search bindings in the identity storage. One of the easiest path is to use the synapse database. So, if none of the identity storage was configured then ma1sd never find this bindings. I can add the internal identity storage to store this bindings if it is impossible to use synapse database or others identity storage (i.e. LDAP).

[mrjohnson22]

My Synapse database's identity storage is correct, though. With psql synapse, manually running the query specified by synapseSql.lookup.query returns a list of users who had bound their email addresses to Synapse.

Could it be that ma1sd isn't connecting to my Synapse database properly? How would I check that? synapseSql.connection should be correct, as it matches the same values used by database.args in my Synapse's homeserver.yaml.

[mrjohnson22]

It turns out my config was the problem after all. The second synapseSql block overrides the first, meaning that enabled, type, andconnection` remain unset. Looking a bit higher in the logs shows that the synapseSql store was disabled entirely.

@ma1uta I'll leave it up to you to decide if split configuration blocks should be allowed. If not, you may close this case.

[ma1uta]

I cannot split configuration because I should support backward compatibility any way.