Email action causing HTTP 400 error

Technical Help
,
1

Please fill in the questionnaire below.

Technical Help Questionnaire

Have you read and followed the instructions at: *READ ME FIRST* Technical Help FAQs - #2 by nigel ?

Yes

Self-Hosted Installation and Setup Questions

Self-host on Ubuntu server 22.04.3 LTS running Docker 24.0.7 and Baserow image from 2023-10-26

What are the specs of the service or server you are using to host Baserow.

VMware EXSi virtual machine with 2 CPU and 8GB of RAM

Which version of Baserow are you using.

1.21.2

How have you configured your self-hosted installation?

BASEROW_EXTRA_ALLOWED_HOSTS	192.168.11.100,192.168.11.88,s___db
BASEROW_IMAGE_TYPE	all-in-one
BASEROW_PLUGIN_DIR	/baserow/data/plugins
BASEROW_PUBLIC_URL	http://s___db
BASEROW_WEBHOOKS_IP_WHITELIST	192.168.11.100,192.168.11.244,192.168.11.88
DATA_DIR	/baserow/data
DOCKER_USER	baserow_docker_user
EMAIL_SMTP	True
EMAIL_SMTP_HOST	192.168.11.26
EMAIL_SMTP_PORT	25
FROM_EMAIL	s___.db@s___.com
GID	9999
NODE_MAJOR	18
PATH	/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
POSTGRES_LOCATION	/etc/postgresql/11/main
POSTGRES_VERSION	11
UID	9999

What commands if any did you use to start your Baserow server?

Started using Portainer CE

Describe the problem

Describe, step by step, how to reproduce the error or problem you are encountering.

I am getting an error from the send invite and forgot password UI whenever I try to have Baserow send an email. The error is “Action Not Completed” with the browser reporting a HTTP 400 response from /api/workspaces/invitations/workspace/92/. This matches the logs from Docker:

baserow_smtp_bad_request_gui2

 [BACKEND][2023-11-16 15:08:00] 127.0.0.1:51126 - "GET /api/_health/ HTTP/1.1" 200  
 [BACKEND][2023-11-16 15:08:00] 192.168.11.142:0 - "POST /api/user/token-refresh/ HTTP/1.1" 200  
 [BACKEND][2023-11-16 15:08:00] WARNING 2023-11-16 15:08:00,737 django.request.log_response:224- Bad Request: /api/workspaces/invitations/workspace/92/   
 [BACKEND][2023-11-16 15:08:00] WARNING 2023-11-16 15:08:00,737 django.request.log_response:224- Bad Request: /api/workspaces/invitations/workspace/92/   
 [BACKEND][2023-11-16 15:08:00] WARNING 2023-11-16 15:08:00,737 django.request.log_response:224- Bad Request: /api/workspaces/invitations/workspace/92/   
 [BACKEND][2023-11-16 15:08:02] 192.168.11.142:0 - "POST /api/workspaces/invitations/workspace/92/ HTTP/1.1" 400  
 [BACKEND][2023-11-16 15:08:23] 127.0.0.1:53248 - "GET /api/_health/ HTTP/1.1" 200  
 [BACKEND][2023-11-16 15:08:41] 127.0.0.1:55304 - "GET /api/_health/ HTTP/1.1" 200  
 [BACKEND][2023-11-16 15:08:43] 127.0.0.1:36514 - "GET /api/_health/ HTTP/1.1" 200 

[BACKEND][2023-11-16 16:48:20] 172.16.20.138:0 - "POST /api/user/token-refresh/ HTTP/1.1" 200  
[BACKEND][2023-11-16 16:48:22] 172.16.20.138:0 - "GET /api/auth-provider/login-options/ HTTP/1.1" 200  
[BACKEND][2023-11-16 16:48:22] 172.16.20.138:0 - "POST /api/user/token-blacklist/ HTTP/1.1" 204  
[BACKEND][2023-11-16 16:48:36] 172.16.20.138:0 - "GET /api/auth-provider/login-options/ HTTP/1.1" 200  
[BACKEND][2023-11-16 16:48:40] 127.0.0.1:53008 - "GET /api/_health/ HTTP/1.1" 200  
[BACKEND][2023-11-16 16:48:40] WARNING 2023-11-16 16:48:40,807 django.request.log_response:224- Bad Request: /api/user/send-reset-password-email/   
[BACKEND][2023-11-16 16:48:40] WARNING 2023-11-16 16:48:40,807 django.request.log_response:224- Bad Request: /api/user/send-reset-password-email/   
[BACKEND][2023-11-16 16:48:40] WARNING 2023-11-16 16:48:40,807 django.request.log_response:224- Bad Request: /api/user/send-reset-password-email/   
[BACKEND][2023-11-16 16:48:51] 172.16.20.138:0 - "POST /api/user/send-reset-password-email/ HTTP/1.1" 400  
[BACKEND][2023-11-16 16:48:56] 127.0.0.1:36834 - "GET /api/_health/ HTTP/1.1" 200

I have tested SMTP using the tool in Admin/Health and it passes and I get an email, so the SMTP backend is working. This makes me wonder if something could have happened at the database level when I migrated from our test system to live system.

I had email working on a test system before migrating to a live server. Migration involved extracting a tarball of baserow/data on the new machine and starting Baserow to chown the data. This worked, all existing tables, users and data is working.

The redoc shows different API responses that I don’t know how to find from the browser developer mode. I might be able to have someone test the api directly if that can yield more details.

Provide screenshots or include share links showing:

How many rows in total do you have in your Baserow tables?

Please attach full logs from all of Baserow’s services

2

I was able to get more information from the browser and it seems this issue is due to the url. The base_url is set to something like: http://mydb/workspace-invitation

Screenshot 2023-11-16 143613

We are using this inside our intranet so the DNS resolves with just the subdomain. i.e. //mydb/ instead of //mydb.mynet.local/. This did not happen on the test machine that uses IP address directly. But if the solution is to set PUBLIC_URL to the full address, then that is not ideal either since everything works and just the email api is rejecting this url. Can I use the public frontend and backend url variables to get around this?

3

Hey @brchan,

I’m sorry to hear it’s not working for you. Unfortunately, the body request is validated with a regex that requires a dot . as separator and a top-level-domain of at least 2 characters to be considered valid when a domain is provided, so at the moment, the only way to make it work is to provide a fully qualified domain name.

I’ll talk with the rest of the team to see if we can do anything else about this.