Hello @dsp76 I have just tested this flow. User with TOTP and passkey configured. Attempt login with username and password: opens the passkey context of bitwarden and shows only the passkey for this user clicking the passkey login success Attempt login with username and password: opens the passkey context of bitwarden closing the bitwarden context without selecting the passkey, falls back to device passkey cancel that as well UI prints Failed to login with passkey, now I can input a TOTP enter TOTP and pressing Login login success Attempt login with passkey: bitwarden context opens showing all passkeys available for this domain selecting my passkey for the user login success Does this flow not work with 1password? Or do you think the flow should be changed so that if multiple 2FA options are configured for a user, the UI asks the user which one to use? Similar to our NodeBB forum when having TOTP and Passkey configured? [image: image.jpeg]

@Nozy I replied from support. The issue seems to be that the box code was created by hand as "CREATE DATABASE box" . However, this gets the incorrect default collation and migrations fail. The correct command is CREATE DATABASE IF NOT EXISTS box CHARACTER SET utf8mb4 COLLATE utf8mb4_bin . I have fixed the docs to state this.

@LoudLemur said: @necrevistonnezr has a valid point, too. What else can we do, though? "Understand it better?" This problem meant people were not receiving emails. Not sending a bug report, particularly when the ai had found a fix, didn't seem public spirited. It also is a bit like self-censorship. It’s pretty simple: Read the output, work with it it, make it your own. Don‘t just forward it unfiltered. If that’s too much, leave it. In case of a bug report, if you don’t want to put in the work, what’s the point? How does the team know your report was verified by you and has merits? It would probably more helpful to leave the team your result in 3-4 sentences and provide the prompt - then they can see for themselves.

That is interesting...

@tobiasb Fixed https://git.cloudron.io/platform/box/-/commit/99cf399454217b113cff1d67ee9ad76a6feadc3f Thanks for reporting.

Great, thank you very much @girish !

Oh no, sorry about that regression and thanks for reporting again! This is fixed then for next release with https://git.cloudron.io/platform/box/-/commit/8a65d11fd176d54f868c2b0067087c4ed07e0a24

does it make sense to disable the feature he keeps using?

you are right. https://git.cloudron.io/platform/box/-/work_items/895 is the work item.

@girish said: @xarp Cloudron does not update or switch the kernel or enable any kernel features, no . There is no code for this. Could it be your VPS provider has switched this by mistake? Thanks for confirming girish.

@girish yes, working now!

@joseph I like the idea of delegating mail to Cloudron entirely and being able to switch mail providers / mail configuration / rotate tokens easily from within the Cloudron UI, so I don't have to edit my own config files / manage SDKs etc. Keeps my apps simple: Just send mail using the envvars and let Cloudron figure it out. The event log is nice too, for monitoring. The setting you mentioned would definitely help a lot, but I have a workable solution now, thanks!

Seems like a valid bug, we can take a look after Cloudron 10.0 . Logged it at https://git.cloudron.io/platform/box/-/work_items/906

@girish said: I have added a 429 check and waiting for "retry-after" in e532401510dc64570f5c0d3d9972429da6268e0f . I guess that's the best we can do on our side . Hi @girish Thanks for this - I appreciate your attempt in trying to help with this. The related server experiencing the issue has been updated to v10.0.2 recently and it seems that this change was part of the update. However, the patch has made the situation worse actually. Since the update, I have been locked out of the related server because the "my." record did not successfully update (or only sporadically, before being scrapped from the DeSEC domain name record table entries shortly after) Attempts to manually add the record to DeSEC entry were also impossible because the DeSEC account was also locked out behind never-ending permanently-resetting with growing threshold waiting times. Not too sure how the Cloudron side is handling this though: It seems like the Cloudron DNS update requests are still batched. e.g. when one record needs updating, all records are updated, no matter if they actually need to. Still seem like Cloudron does not take into account whether or not a record was successfully update. e.g. do DNS record udpate -> if it works great; if it does not, carry on with the next record (thus leaving previous record in limbo) Update task starts at H=x and the next relevant entry is at approx H=x+8 (I suppose this could be due to the threshold retry waiting time) At the moment, the errors on the Cloudron server log oscillate between: reason: 'External Error' reason: 'Database Error' (-> sqlMessage: 'Too many connections',) HTML: 429 too many request HTML: 502 Bad gateway So currently, I feel this is a bit of a mess and I am sorry that this has come down to this. Any idea how this could/should be dealt with? I remain convinced that a more individual approach to DNS record update as well as switching DNS update method to batch HTTP API call would alleviate part of this/the whole issue i.e. only update records that needs updating, prioritze record update ("my." top prio) But I also acknowledge that this seems very specific to DeSEC and might not fit in Cloudron's development plan I hope that this makes sense. Otherwise we will be obliged to move on from DeSEC. @milian.hackradt May I ask what DN server are you using instead of deSEC?

This is fixed for the next patch release with https://git.cloudron.io/platform/box/-/commit/cd4bb20590899618edc4aff4b1117c81567f0e92 Thanks for the report!

Thanks for your prompt response @girish.

Thanks for the report @d19dotca . It's fixed for 10.0.2. The issue was that when having multiple internal forwards, sieve was adding multiple headers. The haraka code headers.get() was concatenating all the headers with '\n' and this caused a crash since I wasn't expecting haraka to concat it this way. There is a get_all() API which returns an array and I pick the latest forwarder from there.

@girish Hi, thank you. That worked perfectly. Not sure how many people would need that function?

With Cloudron 10, the forwarding logic is based on sieve. So, it's identical to roundcube.

The core issue was a quoting problem. It was mistaking "-" as an argument instead of a folder name. Fixed in https://git.cloudron.io/platform/box/-/commit/04adf5de3470a944cf811a23613bceb9ea520b38