Registering always returns: "E-Mail address already in use"

[kromonos]

Ferdium-Server: ferdium/ferdium-server:latest

docker compose:

version: "3.8"
services:
  ferdium-server:
    #image: ferdium/ferdium-server:1.3.16
    image: ferdium/ferdium-server:latest
    container_name: ferdium-server
    environment:
      TZ: 'Europe/Berlin'
      NODE_ENV: 'production'
      #NODE_ENV: 'development'
      APP_URL: 'https://<uri>'
      DB_CONNECTION: 'pg'
      DB_HOST: '127.0.0.1'
      DB_PORT: 5432
      DB_USER: '<un>'
      DB_PASSWORD: '<pw>'
      DB_DATABASE: '<db>'
      DB_SSL: false
      MAIL_CONNECTION: 'smtp'
      SMTP_HOST: '<srv>'
      SMTP_PORT: 465
      MAIL_SSL: true
      MAIL_USERNAME: '<un>'
      MAIL_PASSWORD: '<pw>'
      MAIL_SENDER: '<un>'
      IS_CREATION_ENABLED: true
      IS_DASHBOARD_ENABLED: true
      IS_REGISTRATION_ENABLED: true
      CONNECT_WITH_FRANZ: false
      DATA_DIR: '/data'
      HOST: 127.0.0.1
      PORT: 3017
      JWT_USE_PEM: true
      CACHE_VIEWS: false
    volumes:
      - ferdium-database:/data
      - ferdium-recipes:/app/build/recipes
    restart: unless-stopped
    network_mode: host

volumes:
  ferdium-recipes:
  ferdium-database:

Maybe because of missing recipes, which can't load, because of wrong Node version? See #84 (comment)

**** Generating recipes for first run ****
Cloning into 'recipes'...
npm WARN using --force Recommended protections disabled.

added 1 package in 2s

1 package is looking for funding
  run `npm fund` for details
npm notice
npm notice New major version of npm available! 9.8.1 -> 10.2.3
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.2.3>
npm notice Run `npm install -g npm@10.2.3` to update!
npm notice
 ERR_PNPM_UNSUPPORTED_ENGINE  Unsupported environment (bad pnpm and/or Node.js version)

Your Node version is incompatible with "/app/recipes".

Expected version: 20.9.0
Got: v18.18.0

10:14AM 50 2023/11/08 10:14AM 2023/11/08 10:14AM 50 pid=146 hostname=<hn> name=ferdium-server err={"type":"Error","message":"/app/build/recipes/all.json: ENOENT: no such file or directory, open '/app/build/recipes/all.json'","stack":"Error: /app/build/recipes/all.json: ENOENT: no such file or directory, open '/app/build/recipes/all.json'\n    at Object.openSync (node:fs:603:3)\n    at Object.readFileSync (node:fs:471:35)\n    at Object.readFileSync (/app/node_modules/.pnpm/jsonfile@6.1.0/node_modules/jsonfile/index.js:50:22)\n    at RecipesController.list (/app/app/Controllers/Http/RecipeController.ts:53:32)\n    at Injector.callAsync (/app/node_modules/.pnpm/@adonisjs+fold@8.2.0/node_modules/@adonisjs/fold/build/src/Ioc/Injector.js:124:30)","errno":-2,"syscall":"open","code":"ENOENT","path":"/app/build/recipes/all.json","status":500} msg=/app/build/recipes/all.json: ENOENT: no such file or directory, open '/app/build/recipes/all.json'

[npXXX]

I have the same issue but with a "non-docker" setup, when trying to register a new account I always get the response "E-Mail address already in use". Dev tools show a 401 Unauthorized on /v1/auth/signup route

[thetonk]

I face the same issue, with clean installation of latest version on docker, using mySQL/mariaDB database. Server fails to insert new users on database, throwing the same 401 error mentioned, although database connection is working properly since it gets populated with tables and the initial migration entries. Using the default SQLite database by adding the proper user and group on docker compose, it registers new users without any problems. Probably something is wrong with remote database management.

[357up]

This is issue with table's users (more specifically the column password) schema in MySQL (I haven't tested postgres or sqlite).
This is the schema created by the application:

CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(80) NOT NULL,
  `email` varchar(254) NOT NULL,
  `password` varchar(60) NOT NULL,
  `settings` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(`settings`)),
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `lastname` varchar(80) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `users_email_unique` (`email`)
)

As we can see the max size of the password field is 60.
However, using strace command, I was able to retrieve the SQL insert application generates upon signup:

The resulting hashed password was 133 characters long and the insert just errored out.

Most important issue is probably that the error handling when interacting with DB is either missing or broken. And of course, the schema should be fixed as well.

For those that are running into this issue (while the schema hasn't been fixed by the maintainers), running following SQL should fix the issue:

ALTER TABLE `users` MODIFY `password` VARCHAR(254) NOT NULL;

[kromonos]

@357up nice workaround. Thanks for this :)

[thuvh]

This is issue with table's users (more specifically the column password) schema in MySQL (I haven't tested postgres or sqlite). This is the schema created by the application:

I haven't got any problems with postgres.

[bioluks]

I myself was getting the nodejs warning, that v20.11.0 isn't enough for the recipes. Built the container myself wth the official Dockerfile which fixed this issue immediately. Since I'm no database pro the comment from @357up really solved the "E-Mail already in use" error for me as well! As a PostgreSQL user the command changes a little bit:

ALTER TABLE users ALTER COLUMN password TYPE varchar(254) ALTER COLUMN password SET NOT NULL;

Sad to see it's not fixed since November '23, since this is probably affecting all new instances. Will send a PR probably.

[xX-MrN0b0dy-Xx]

New fresh setup with ferdium/ferdium-server:2.0.10 (latest dec 2024 release) and mariadb:11.5.2 here and same error as described above: "A user with that email address already exists" for any Sign Up.

Entering the DB inside the container and showing the SCHEMA, this is returned:

*************************** 1. row ***************************
       Table: users
Create Table: CREATE TABLE `users` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(80) NOT NULL,
  `email` varchar(254) NOT NULL,
  `password` varchar(60) NOT NULL,
  `settings` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(`settings`)),
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `lastname` varchar(80) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `users_email_unique` (`email`)
)

So I applied the workaround proposed by @357up and it worked like a charm.

#129 report same error and a PR is still under review I think

[piscis]

I encountered the same problem with a fresh install of Ferdium Server (2.0.10) and MariaDB (11.x), but I was able to fix it with:

ALTER TABLE users MODIFY COLUMN password VARCHAR(254) NOT NULL;

The solution from this comment did not work for me because of sql error on mariadb

[xX-MrN0b0dy-Xx]

I encountered the same problem with a fresh install of Ferdium Server (2.0.10) and MariaDB (11.x), but I was able to fix it with:

ALTER TABLE users MODIFY COLUMN password VARCHAR(254) NOT NULL;

The solution from this comment did not work for me because of sql error on mariadb

I don't understand: for the command MODIFY the keyword COLUMN is optional... while the backticks explicitly quotes the modifiers that is useful if contains special characters or whatever...

Anyway, what is important is that the PR has to be accepted.

[BashkaOpuhla]

Ferdium Server 2.0.11 with standalone "non-docker" setup and PostgreSQL DB. Registering always returns: "E-Mail address already in use"

FIX for PostgreSQL 17:

ALTER TABLE users ALTER COLUMN password TYPE VARCHAR(254), ALTER COLUMN password SET NOT NULL;

or you can change it manually via pgAdmin GUI

[fschaupp]

This is issue with table's users (more specifically the column password) schema in MySQL (I haven't tested postgres or sqlite). This is the schema created by the application:

CREATE TABLE users (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
username varchar(80) NOT NULL,
email varchar(254) NOT NULL,
password varchar(60) NOT NULL,
settings longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(settings)),
created_at datetime DEFAULT NULL,
updated_at datetime DEFAULT NULL,
lastname varchar(80) NOT NULL DEFAULT '',
PRIMARY KEY (id),
UNIQUE KEY users_email_unique (email)
)

As we can see the max size of the password field is 60. However, using strace command, I was able to retrieve the SQL insert application generates upon signup:

The resulting hashed password was 133 characters long and the insert just errored out.

Most important issue is probably that the error handling when interacting with DB is either missing or broken. And of course, the schema should be fixed as well.

For those that are running into this issue (while the schema hasn't been fixed by the maintainers), running following SQL should fix the issue:

ALTER TABLE users MODIFY password VARCHAR(254) NOT NULL;

Having looked into it again, it seems from a DevEx perspective, logging via enabling trace-level definitely should have revealed the issue here

ferdium-server/app/Controllers/Http/UserController.ts

Line 87 in 1572e87

return response.status(401).send({

Is it just me, or is there also no test coverage about the registration path?