Generic errors on web UI for Create New Alias, Add Recipient, Deactivate Alias - Insufficient debug info

[buxm]

Behaviour

When I operate on the web interface on aliases and recipients, I get generic errors:

Error
An error has occurred, please try again later

Container logs are showing:

"DELETE /api/v1/allowed-recipients/c499911b-026c-4931-8204-a9a3b1345381 HTTP/1.1" 401 41 "https://anonaddy.mydomain.com/recipients" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"
"POST /api/v1/recipients HTTP/1.1" 401 41 "https://anonaddy.mydomain.com/recipients" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"
"DELETE /api/v1/active-aliases/10dfc096-75d5-41b0-b0f1-d80864d34c7c HTTP/1.1" 401 41 "https://anonaddy.mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"

So apparently the requests are not authorised. But I have no clue how to understand why they are not authorised. I correctly logged into the web interface.
Probably it's something wrong in my set up, but no clue where to look. I'm going crazy, the only options are to randomly change settings. I've also wiped and re-initiated the DB from scratch, to no avail.

I would need some more debug info, but APP_DEBUG=true and I don't know what I can do more.

Steps to reproduce this issue

1. Log in to the web interface
2. deactivate aliases
3. create aliases
4. add recipients
5. do stuff and watch errors coming up, but no info on the reason

Image Release: 0.13.9-r0

[buxm]

After tinkering a lot today with different settings, I have realised that the reported errors occur with image tags starting from 0.13.3 upwards.
More specifically, I tested the "create new alias" function on the web UI and it works with image tags 0.11.2 and 0.12.3, while it returns an error with image tags 0.13.3, 0.13.4, 0.13.7 and 0.13.9.
So I am a bit less convinced that this is down to some misconfiguration on my setup.
Hopefully I'll have time to tinker a bit more tomorrow.

[buxm]

No chance. I couldn't find any further clue as to what is causing the issue. I'm providing here a full bug report, in the hope that someone can either point me in the right direction or find a bug in the docker image.

Behaviour

Steps to reproduce this issue

1. Deploy anonaddy docker image tag 0.13.3 or higher starting from an empty database.
2. Register on the web UI with the ANONADDY_ADMIN_USERNAME
3. Verify email address & login
4. click on "Create New Alias" in Aliases
5. Click "Create Alias"

Expected behaviour

The alias is created successfully.
Even in case of error, the container logs in debug mode provide some more info on where the error occurred than a simple HTTP code.

Actual behaviour

A red popup appears in the lower right corner:

Error
An error has occurred, please try again later

Configuration

• Docker version (type docker --version) : Docker version 20.10.21, build baeda1f
• Docker compose version if applicable (type docker-compose --version) : Docker Compose version v2.12.2
• Platform (Debian 9, Ubuntu 18.04, ...) : Canonical-Ubuntu-22.04-Minimal-aarch64-2022.08.16-0
• System info (type uname -a) : Linux email4ward01 5.15.0-1021-oracle # 27-Ubuntu SMP Fri Oct 14 20:04:20 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux
• Include all necessary configuration files : docker-compose.yml, .env, ...
  config files.zip
  deployed with the following commands:

docker stack deploy -c docker-compose.db.single.yml anonaddy_db
docker stack deploy -c docker-compose.anonaddy.single.yml Anonaddy

Docker info

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.9.1-docker)
  compose: Docker Compose (Docker Inc., v2.12.2)

Server:
 Containers: 6
  Running: 5
  Paused: 0
  Stopped: 1
 Images: 38
 Server Version: 20.10.21
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: journald
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: active
  NodeID: k0qsu4qv27ncgiusbpk5fv5sq
  Is Manager: true
  ClusterID: nbuhooquvm4tgvian9voockw2
  Managers: 3
  Nodes: 3
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 192.168.128.94
  Manager Addresses:
   192.168.128.78:2377
   192.168.128.82:2377
   192.168.128.94:2377
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1c90a442489720eec95342e1789ee8a5e1b9536f
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.15.0-1021-oracle
 Operating System: Ubuntu 22.04.1 LTS
 OSType: linux
 Architecture: aarch64
 CPUs: 1
 Total Memory: 1.92GiB
 Name: email4ward01
 ID: JR2T:77DW:NZPP:IMO3:UY5I:R3ZW:LKBN:ICL6:MASZ:CWBO:OYBA:BUU6
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Logs

"POST /api/v1/aliases HTTP/1.1" 401 41 "https://anonaddy.mydomain.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"

no logs in /docker/data/Anonaddy/data/storage/logs/

[willbrowningme]

Have you read this issue - #150

and made sure to add the right value for SANCTUM_STATEFUL_DOMAINS?

[buxm]

@willbrowningme no, I didn't see issue #150.

So I have now set SANCTUM_STATEFUL_DOMAINS=anonaddy.mydomain.com (i.e. the domain name I put in my browser to reach the web UI) and now it works!!! :-)

I have also realised that my APP_URL variable wasn't quite correct. By using a Cloudflare tunnel I reach the web UI by putting https://anonaddy.mydomain.com in my browser; then Cloudflare tunnel acts as a rev proxy and calls the actual web UI at http://localhost:8000. So I changed it with the correct version, but it didn't help without also setting SANCTUM_STATEFUL_DOMAINS. I also set APP_URL with a completely wrong domain, but it didn't seem to make any difference for good or bad. I am not quite sure what APP_URL is needed for.

Many thanks for your help!
I'd suggest adding something to the documentation about SANCTUM_STATEFUL_DOMAINS. Or maybe you're thinking of some fix that doesn't require an additional variable and maybe figures out the correct setup based on APP_URL...

[crazy-max]

So I have now set SANCTUM_STATEFUL_DOMAINS=anonaddy.mydomain.com (i.e. the domain name I put in my browser to reach the web UI) and now it works!!! :-)

That's strange, SANCTUM_STATEFUL_DOMAINS is already set with:

docker/rootfs/etc/cont-init.d/13-config-anonaddy.sh

Line 64 in aac8ad2

SANCTUM_STATEFUL_DOMAINS="${ANONADDY_DOMAIN}"

So if ANONADDY_DOMAIN is correct it should work.

[buxm]

@crazy-max
In my case ANONADDY_DOMAIN=mydomain.com.
As per the documentation:

ANONADDY_DOMAIN: Root domain to receive email from

So, in my case I want anonaddy to send emails from @mydomain.com or @*.mydomain.com.

However SANCTUM_STATEFUL_DOMAINS=anonaddy.mydomain.com, which is the FQDN I am using for the web app.
That's because I have to point my browser to https://anonaddy.mydomain.com to log into the web UI, not to https://mydomain.com.
So I think this explains.

In my case I didn't want to point my browser to https://mydomain.com (i.e. ANONADDY_DOMAIN) to reach the web UI.
With the test domain I am curently using to test & tinker with Anonady, https://mydomain.com is already being used for another web site.
But even with a production domain, I am not sure I would always want to have Anonaddy's web UI to respond on the root domain (like in https://mydomain.com), since it could also be taken by something else.

[crazy-max]

That makes sense. Wonder if we should not infer SANCTUM_STATEFUL_DOMAINS from APP_URL instead.

[buxm]

@crazy-max I think that would make a lot of sense.

[buxm]

@crazy-max thanks a lot!
I positive and negative tested image tag 0.13.11 only playing with APP_URL and not setting SANCTUM_STATEFUL_DOMAINS.
It seems to be working as expected.

APP_URL needs to include the correct port. E.g. if you set APP_URL=http://anonaddy.mydomain.com but then you reach the web app by http://anonaddy.mydomain.com:8000 you'll get the errors mentioned above. You'll need to set APP_URL=http://anonaddy.mydomain.com:8000 to make it work in this scenario.

On the other hand, it doesn't seem to matter whether you set APP_URL=http://anonaddy.mydomain.com but you reach the web app by https://anonaddy.mydomain.com. Or viceversa. The web app will work ok regardless of http or https.

But you do need to put either http:// or https:// at the beginning of APP_URL. Setting APP_URL=anonaddy.mydomain.com when the web app is reachable by http(s)://anonaddy.mydomain.com will make those red box errors pop up again.

Overall, this all makes sense to me. By following the documentation and the examples it should be sufficiently intuitive to get things right.

[robsiera]

I needed to remove the http from my APP_URL to get it working without explicitly setting SANCTUM_STATEFUL_DOMAINS.