stuck on sign in for new account

[BrutalBirdie]

There is one 404 error when opening element for me and the same error.

Aug 02 22:54:24 [2021-08-02T20:54:24.897Z] "GET /config.element.deadsec.net.json?cachebuster=1627937670348" Error (404): "Not found"

But this seems not be an Element Issue but more a Matrix Home Server issue, since I can login with my @brutalbirdie:matrix.org username.

If I give Element the explicit login this error appears.

And the federation check seems also OK.

https://federationtester.matrix.org/#deadsec.net

---

restarting both did also not help.

Hmmmm

[BrutalBirdie]

OK so this should be a Matrix Home Server Problem.
Since even when using https://app.element.io/#/login with the explicit login it also throws the error.

---

I even restored the app to version 1.27.1 and the issue persists. What is going on here?
Well I changed my DNS to Cloudflare and have the subdomains proxied. Maybe there is something about that.

[ianhyzy]

@brutalbirdie said in stuck on sign in for new account:

Well I changed my DNS to Cloudflare and have the subdomains proxied. Maybe there is something about that.

I'm using Gandi DNS so it doesn't seem limited to cloudflare, but I'm trying to dig into the homeserver now

[BrutalBirdie]

@ianhyzy questionable since I even restored the version before and the issue is the same. Time for a Cloudron reboot
Have to do that anyway.

---

Edit nope issue persists.

[humptydumpty]

Element/Matrix are working fine on my server. I can sign in with the iOS mobile app, on Element (self-hosted on CR) and on Element (app.element.io) by editing the homeserver and using mine. All's good.

Cloudron app details:
Matrix: org.matrix.synapse@1.28.0
Element: im.riot.cloudronapp@1.5.14
Cloudron: v6.3.5 (Ubuntu 20.04.2 LTS)

I'm not running a proxy or cloudflare.. maybe that's the issue? lmk if you need me to test anything on my end.

[ianhyzy]

This post is deleted!

[ianhyzy]

I have my desktop app open and I can still send messages, but no dice on login - extremely weird. Nothing in logs at all other than that cachebuster error.

also turned on debug mode but it doesn't seem to be showing me anything more.

loggers:
  synapse.storage.SQL:
    # beware: increasing this to DEBUG will make synapse log sensitive
    # information such as access tokens.
    level: DEBUG
  twisted:
    # We send the twisted logging directly to the file handler,
    # to work around https://github.com/matrix-org/synapse/issues/3471
    # when using "buffer" logger. Use "console" to log to stderr instead.
    handlers: [file]
    propagate: false
root:
  level: DEBUG
  # Write logs to the `buffer` handler, which will buffer them together in memory,
  # then write them to a file.
  #
  # Replace "buffer" with "console" to log to stderr instead. (Note that you'll
  # also need to update the configuration for the `twisted` logger above, in
  # this case.)
  #
  handlers: [buffer]
disable_existing_loggers: false

[girish]

@ianhyzy Did you install synapse with Cloudron user integration disabled? Earlier I had reported an issue along these lines at https://github.com/matrix-org/matrix-synapse-ldap3/issues/124 . If you installed Synapse with Cloudron user integration disabled, then can you check homeserver.yml and ensure that it does not have the Ldap configuration ? If there is some ldap configuration just remove it entirely and restart synapse. Note that there is a "disabled" flag but that does nothing (I reported that as https://github.com/matrix-org/matrix-synapse-ldap3/issues/123)

[girish]

I thought I automatically deleted the password_providers section when user management is disabled with https://git.cloudron.io/cloudron/synapse-app/-/commit/6775418dafd900ddd5dd7ce9201014f227571de7 but maybe I got something wrong.

[ianhyzy]

@girish
Interesting, yes I did have this:

password_providers:
  - module: "synapse.util.ldap_auth_provider.LdapAuthProvider"
    config:
      enabled: true
      uri: "ldap://ldap.example.com:389"
      start_tls: true
      base: "ou=users,dc=example,dc=com"
      attributes:
        uid: "username"
        mail: "mail"
        name: "username"
      bind_dn: "ou=users,dc=cloudron"
      bind_password: "password"
      filter: "(objectClass=posixAccount)"

so i deleted it and boom, working again! Cloudron support remains unmatched in speed and ticket resolution time

[girish]

@ianhyzy oh I made a mistake in the script.

[girish]

I fixed this in package 1.28.0-1