Originally posted by knightian October 2, 2023
Latest version of vaultwarden and web vault
If I make a secure note in the webvault, it does not appear soon in the app on iOS.
I did a fresh generation of installation id and password for the config, and then I deleted the iOS app and reinstalled it so it would set up the push notifications in the app as per the wiki, but it does not work.
It used to work in previous versions.
There are no DNS issues at the moment because I am putting nameserver entry in resolv.conf to make trust-dns happy:
Your environment (Generated via diagnostics page)
Vaultwarden version: v1.29.2-bc26bfa5
Web-vault version: v2023.8.2
OS/Arch: linux/x86_64
Running within Docker: false (Base: Not applicable)
<!-- gh-comment-id:1757143591 -->
@techfoxactual commented on GitHub (Oct 11, 2023):
Not sure why this issue keeps getting closed, multiple people have the issue now https://github.com/dani-garcia/vaultwarden/discussions/3945
It gets closed because we can't fix this.
It works for a lot of other people. And we can't debug the server side stuff!!
<!-- gh-comment-id:1757150686 -->
@BlackDex commented on GitHub (Oct 11, 2023):
It gets closed because we can't fix this.
It works for a lot of other people. And we can't debug the server side stuff!!
@techfoxactual commented on GitHub (Oct 11, 2023):
@BlackDex can you at least put debug logging for the stuff this side so we can trace it and report? Or are you saying that you have tested it and found that it is an error on Bitwarden push server side?
<!-- gh-comment-id:1757153983 -->
@techfoxactual commented on GitHub (Oct 11, 2023):
@BlackDex can you at least put debug logging for the stuff this side so we can trace it and report? Or are you saying that you have tested it and found that it is an error on Bitwarden push server side?
@knightian I don't understand what you want with debugging which only tells you that something is being sent out.
One, if the DNS queries are visible, then it is send out. Second if there is an error that will be shown in the logs.
But as mentioned before, there are probably no errors! Since you would have seen those in the logs!
And everything sent to the Bitwarden Push environment is after that out of our control.
Not sure what you want more?
Also, we do except well written PR's, and you can also debug it locally via a mitmproxy or something!
A nice tool for this could be mitmproxy, which is what i also use for stuff like this instead of adding very very verbose debugging into a product which only adds extra load.
Also i want to make it clear that this project is mostly run by less then 1 hand full of people, who maintain this in there free spare time. This is an Open Source project without any warranties.
And complaining about dev's not wanting to put more debugging into something because they are busy with other stuff is out of proportion.
Also, besides this, i have mentioned the mitmproxy route before, and if people do not want to use that, that is fine, but don't come complain we don't want to help. We need more information, but again, you won't get it by adding more debugging and more output since again, errors will show in the logs. But hey, if you do not trust me on that, go and help us fix the code instead of complaining, that is not the Open Source way of thinking and working.
<!-- gh-comment-id:1757298415 -->
@BlackDex commented on GitHub (Oct 11, 2023):
@knightian I don't understand what you want with debugging which only tells you that something is being sent out.
One, if the DNS queries are visible, then it is send out. Second if there is an error that will be shown in the logs.
But as mentioned before, there are probably no errors! Since you would have seen those in the logs!
And everything sent to the Bitwarden Push environment is after that out of our control.
Not sure what you want more?
Also, we do except well written PR's, and you can also debug it locally via a mitmproxy or something!
A nice tool for this could be [mitmproxy](https://docs.mitmproxy.org/stable/), which is what i also use for stuff like this instead of adding very very verbose debugging into a product which only adds extra load.
Also i want to make it clear that this project is mostly run by less then 1 hand full of people, who maintain this in there free spare time. This is an Open Source project without any warranties.
And complaining about _dev's_ not wanting to put more debugging into something because they are busy with other stuff is out of proportion.
Also, besides this, i have mentioned the mitmproxy route before, and if people do not want to use that, that is fine, but don't come complain we don't want to help. We need more information, but again, you won't get it by adding more debugging and more output since again, errors will show in the logs. But hey, if you do not trust me on that, go and help us fix the code instead of complaining, that is not the Open Source way of thinking and working.
I am experiencing the same issue, I set it up using US server but still, push is not working.
push_token is populated for my apple devices as I verified using sqlite, but no go.
From evidence I gathered however it does NOT seem to be an issue with vaultwarden, but rather on bitwarden end.. (or, vaultwarden is sending incorrect data but thats out of my reach to check.)
root@d-server:/volume1/docker/vaultwarden# sqlite3 db.sqlite3 "SELECT name,push_token FROM devices WHERE push_token IS NOT NULL;"
iPad11,6|<redacted>
iPhone16,1|<redacted>
iPhone15,2|<redacted>
Container is properly accessing the domain as verified using adguard home query history:
¯\(ツ)/¯
<!-- gh-comment-id:1797001320 -->
@pduchnovsky commented on GitHub (Nov 6, 2023):
I am experiencing the same issue, I set it up using US server but still, push is not working.
push_token is populated for my apple devices as I verified using sqlite, but no go.
From evidence I gathered however it does NOT seem to be an issue with vaultwarden, but rather on bitwarden end.. (or, vaultwarden is sending incorrect data but thats out of my reach to check.)
```
root@d-server:/volume1/docker/vaultwarden# sqlite3 db.sqlite3 "SELECT name,push_token FROM devices WHERE push_token IS NOT NULL;"
iPad11,6|<redacted>
iPhone16,1|<redacted>
iPhone15,2|<redacted>
```
Container is properly accessing the domain as verified using adguard home query history:
¯\\_(ツ)_/¯
I got it to work, what I did is I used mitm proxy to try and debug what was happening, and I trusted the certificate for mitm proxy to be able to inspect the HTTPS messages...... it seems that by trusting the mitm proxy it all started working. Maybe vaultwarden is seeing some certificate trust issues for one of the bitwarden push domains or something like that.
<!-- gh-comment-id:1797087713 -->
@techfoxactual commented on GitHub (Nov 7, 2023):
I got it to work, what I did is I used mitm proxy to try and debug what was happening, and I trusted the certificate for mitm proxy to be able to inspect the HTTPS messages...... it seems that by trusting the mitm proxy it all started working. Maybe vaultwarden is seeing some certificate trust issues for one of the bitwarden push domains or something like that.
@knightian , that isn't possible. You only added a trust for the mitm cert, not others i think. Also, you would have seen a cert error message in that case.
Maybe it's just coincidence 🤔.
<!-- gh-comment-id:1797908205 -->
@BlackDex commented on GitHub (Nov 7, 2023):
@knightian , that isn't possible. You only added a trust for the mitm cert, not others i think. Also, you would have seen a cert error message in that case.
Maybe it's just coincidence 🤔.
You only added a trust for the mitm cert, not others i think
Yea but the mitm proxy uses its certificate for every connection, basically vaultwarden sees only the mitm proxy certificate for every single URL. You're right though, it could be a coincidence which is why I didn't bother to mention it until now.
<!-- gh-comment-id:1797920444 -->
@techfoxactual commented on GitHub (Nov 7, 2023):
> You only added a trust for the mitm cert, not others i think
Yea but the mitm proxy uses its certificate for every connection, basically vaultwarden sees only the mitm proxy certificate for every single URL. You're right though, it could be a coincidence which is why I didn't bother to mention it until now.
But, are you still using the mitm? If not, and it is still working, then it can't be the cert. If you are still using the mitm, it could maybe, but i would suggest to stop it, not very secure.
<!-- gh-comment-id:1797925638 -->
@BlackDex commented on GitHub (Nov 7, 2023):
But, are you still using the mitm? If not, and it is still working, then it can't be the cert. If you are still using the mitm, it could maybe, but i would suggest to stop it, not very secure.
Nah I'm not using it now. I'm wondering if it was the registration process of the device failing and then when I used mitm it registered and now it continues to work ever since.
<!-- gh-comment-id:1797929203 -->
@techfoxactual commented on GitHub (Nov 7, 2023):
Nah I'm not using it now. I'm wondering if it was the registration process of the device failing and then when I used mitm it registered and now it continues to work ever since.
But that doesn't explain the situation I highlighted above, where I have the push_token for all three apple devices (thus means they got registered already) and yet the push does not work at all :/
<!-- gh-comment-id:1798344928 -->
@pduchnovsky commented on GitHub (Nov 7, 2023):
But that doesn't explain the situation I highlighted above, where I have the push_token for all three apple devices (thus means they got registered already) and yet the push does not work at all :/
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @techfoxactual on GitHub (Oct 11, 2023).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/3968
Discussed in https://github.com/dani-garcia/vaultwarden/discussions/3945
Originally posted by knightian October 2, 2023
Discussed in https://github.com/dani-garcia/vaultwarden/discussions/3943
Originally posted by knightian October 2, 2023
Latest version of vaultwarden and web vault
If I make a secure note in the webvault, it does not appear soon in the app on iOS.
I did a fresh generation of installation id and password for the config, and then I deleted the iOS app and reinstalled it so it would set up the push notifications in the app as per the wiki, but it does not work.
It used to work in previous versions.
There are no DNS issues at the moment because I am putting nameserver entry in resolv.conf to make trust-dns happy:
Your environment (Generated via diagnostics page)
Config (Generated via diagnostics page)
Show Running Config
Environment settings which are overridden:
@techfoxactual commented on GitHub (Oct 11, 2023):
Not sure why this issue keeps getting closed, multiple people have the issue now https://github.com/dani-garcia/vaultwarden/discussions/3945
@BlackDex commented on GitHub (Oct 11, 2023):
It gets closed because we can't fix this.
It works for a lot of other people. And we can't debug the server side stuff!!
@techfoxactual commented on GitHub (Oct 11, 2023):
@BlackDex can you at least put debug logging for the stuff this side so we can trace it and report? Or are you saying that you have tested it and found that it is an error on Bitwarden push server side?
@BlackDex commented on GitHub (Oct 11, 2023):
@knightian I don't understand what you want with debugging which only tells you that something is being sent out.
One, if the DNS queries are visible, then it is send out. Second if there is an error that will be shown in the logs.
But as mentioned before, there are probably no errors! Since you would have seen those in the logs!
And everything sent to the Bitwarden Push environment is after that out of our control.
Not sure what you want more?
Also, we do except well written PR's, and you can also debug it locally via a mitmproxy or something!
A nice tool for this could be mitmproxy, which is what i also use for stuff like this instead of adding very very verbose debugging into a product which only adds extra load.
Also i want to make it clear that this project is mostly run by less then 1 hand full of people, who maintain this in there free spare time. This is an Open Source project without any warranties.
And complaining about dev's not wanting to put more debugging into something because they are busy with other stuff is out of proportion.
Also, besides this, i have mentioned the mitmproxy route before, and if people do not want to use that, that is fine, but don't come complain we don't want to help. We need more information, but again, you won't get it by adding more debugging and more output since again, errors will show in the logs. But hey, if you do not trust me on that, go and help us fix the code instead of complaining, that is not the Open Source way of thinking and working.
@pduchnovsky commented on GitHub (Nov 6, 2023):
I am experiencing the same issue, I set it up using US server but still, push is not working.
push_token is populated for my apple devices as I verified using sqlite, but no go.
From evidence I gathered however it does NOT seem to be an issue with vaultwarden, but rather on bitwarden end.. (or, vaultwarden is sending incorrect data but thats out of my reach to check.)
Container is properly accessing the domain as verified using adguard home query history:
¯\(ツ)/¯
@techfoxactual commented on GitHub (Nov 7, 2023):
I got it to work, what I did is I used mitm proxy to try and debug what was happening, and I trusted the certificate for mitm proxy to be able to inspect the HTTPS messages...... it seems that by trusting the mitm proxy it all started working. Maybe vaultwarden is seeing some certificate trust issues for one of the bitwarden push domains or something like that.
@BlackDex commented on GitHub (Nov 7, 2023):
@knightian , that isn't possible. You only added a trust for the mitm cert, not others i think. Also, you would have seen a cert error message in that case.
Maybe it's just coincidence 🤔.
@techfoxactual commented on GitHub (Nov 7, 2023):
Yea but the mitm proxy uses its certificate for every connection, basically vaultwarden sees only the mitm proxy certificate for every single URL. You're right though, it could be a coincidence which is why I didn't bother to mention it until now.
@BlackDex commented on GitHub (Nov 7, 2023):
But, are you still using the mitm? If not, and it is still working, then it can't be the cert. If you are still using the mitm, it could maybe, but i would suggest to stop it, not very secure.
@techfoxactual commented on GitHub (Nov 7, 2023):
Nah I'm not using it now. I'm wondering if it was the registration process of the device failing and then when I used mitm it registered and now it continues to work ever since.
@pduchnovsky commented on GitHub (Nov 7, 2023):
But that doesn't explain the situation I highlighted above, where I have the push_token for all three apple devices (thus means they got registered already) and yet the push does not work at all :/