Originally created by @AndrewPaglusch on GitHub (Dec 24, 2018).
Environment Information
Docker Image: mprasil/bitwarden:latest (Fully up-to-date. Image ID: 68111df54627) Bitwarden Mac Client: v1.11.2 on macOS High Sierra Bitwarden Android Client: v1.21.0 on Android 9 (Path Level Dec 5, 2018)
Updating entries on the Android client works normally.
Creating new entries on the Mac client works normally.
Editing other entries works normally.
So far, I have only experienced this issue with this one entry.
What I've Already Tried:
Restarting Bitwarden docker container
Updating Docker image (was fully up-to-date)
Checking for updates on Mac client (was fully up-to-date)
Logging out/in on Mac client
Re-syncing vault on Mac client
Originally created by @AndrewPaglusch on GitHub (Dec 24, 2018).
### Environment Information
**Docker Image:** mprasil/bitwarden:latest (Fully up-to-date. Image ID: 68111df54627)
**Bitwarden Mac Client:** v1.11.2 on macOS High Sierra
**Bitwarden Android Client:** v1.21.0 on Android 9 (Path Level Dec 5, 2018)
#### Docker Compose Configuration
```
version: '2'
services:
bitwarden:
image: mprasil/bitwarden:latest
container_name: bitwarden
restart: always
volumes:
- ./bitwarden/data:/data
ports:
- 127.0.0.100:8080:80
- 127.0.0.100:3012:3012
environment:
- WEBSOCKET_ENABLED=true
- SIGNUPS_ALLOWED=true
- INVITATIONS_ALLOWED=false
- SERVER_ADMIN_EMAIL=<REDACTED>
restart: always
```
#### Nginx Configuration
```
server {
listen 80;
server_name <REDACTED>;
location ~ /.well-known {
root /var/www/<REDACTED>/htdocs;
allow all;
}
location / {
rewrite ^ https://$host$request_uri? permanent;
}
}
server {
listen 443 ssl;
server_name <REDACTED>;
ssl_certificate /etc/letsencrypt/live/<REDACTED>/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/<REDACTED>/privkey.pem;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;
# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;
# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;
#allow large uploads
client_max_body_size 100m;
location ~ /.well-known {
root /var/www/<REDACTED>/htdocs;
allow all;
}
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
proxy_pass http://127.0.0.100:8080;
}
location /notifications/hub {
proxy_pass http://127.0.0.100:3012;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /notifications/hub/negotiate {
proxy_pass http://127.0.0.100:8080;
}
}
```
### Problem
When trying to save a specific entry on the Mac client, the following error is logged in the docker container:
```
bitwarden | [2018-12-24][15:21:08][rocket::rocket][INFO] PUT /api/ciphers/000bfe5c-b808-4ee8-8abc-1ac733687304 application/json; charset=utf-8:
bitwarden | [2018-12-24][15:21:08][_][INFO] Matched: PUT /api/ciphers/<uuid> (put_cipher)
bitwarden | [2018-12-24][15:21:08][_][ERROR] Couldn't parse JSON body: Error("missing field `Key`", line: 1, column: 1869)
bitwarden | [2018-12-24][15:21:08][_][INFO] Outcome: Failure
bitwarden | [2018-12-24][15:21:08][_][WARN] Responding with 422 Unprocessable Entity catcher.
bitwarden | [2018-12-24][15:21:08][_][INFO] Response succeeded.
```
The following is logged in the Nginx access log:
```
<REDACTED> - - [24/Dec/2018:15:39:26 +0000] "PUT /api/ciphers/000bfe5c-b808-4ee8-8abc-1ac733687304 HTTP/1.1" 422 573 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Bitwarden/1.11.2 Chrome/61.0.3163.100 Electron/2.0.11 Safari/537.36" "-"
```
Nothing is logged to the Nginx error log.
The client displays the following message. The entry is never saved.
> An error has occurred. An unexpected error has occurred
This seems similar to this issue: #253
### What Works
- Updating entries on the Android client works normally.
- Creating new entries on the Mac client works normally.
- Editing other entries works normally.
So far, I have only experienced this issue with this one entry.
### What I've Already Tried:
- Restarting Bitwarden docker container
- Updating Docker image (was fully up-to-date)
- Checking for updates on Mac client (was fully up-to-date)
- Logging out/in on Mac client
- Re-syncing vault on Mac client
@AndrewPaglusch commented on GitHub (Dec 24, 2018):
I just found something interesting. This secret had a .json file attached to it. I removed the JSON attachment, re-synced the vault, and then was able to edit the secret without any problems. If I re-add the attachment and then save and re-sync the vault, I am no longer able to make changes to the secret again.
Is it possible that the JSON attachment is being parsed? I've just verified that it's valid JSON, if that makes any difference.
@AndrewPaglusch commented on GitHub (Dec 24, 2018):
I just found something interesting. This secret had a `.json` file attached to it. I removed the JSON attachment, re-synced the vault, and then was able to edit the secret without any problems. If I re-add the attachment and then save and re-sync the vault, I am no longer able to make changes to the secret again.
Is it possible that the JSON attachment is being parsed? I've just verified that it's valid JSON, if that makes any difference.
The file format shouldn't matter, as it would be sent already encrypted, so I imagine it would happen with any file type. Can you check what data is sent from the developer tools (View > Toggle Dev Tools > Network > Select XHR Only)?
I don't have a Mac to test, but when I try to update a cipher with an attachment from the web vault, it sends something like this:
It should be the same for the mac client. Does it work for you from the web vault?
The error seems to imply that the key inside attachments2 is not being sent for some reason. The individual keys per attachment is a recent change, so I can see how an old attachment that hasn't been migrated to the new model might fail here, but if you re-addded the attachment in the new version then I don't know why it's breaking.
@dani-garcia commented on GitHub (Dec 24, 2018):
The file format shouldn't matter, as it would be sent already encrypted, so I imagine it would happen with any file type. Can you check what data is sent from the developer tools (View > Toggle Dev Tools > Network > Select XHR Only)?
I don't have a Mac to test, but when I try to update a cipher with an attachment from the web vault, it sends something like this:
```
{
"type": 1,
"folderId": null,
"organizationId": null,
"name": "2.6CK0A/DqmEilsKTfVDWLog==|==|GZgQYY6/aIbA=",
"notes": null,
"favorite": false,
"login": {
"uris": null,
"username": "2.LSu9dJVZDIaWblDXYO2NwA==|==|/F5JJxcxAzjs0as7OJ8bbBwE+8=",
"password": "2.JoO8nw/==|==|8SILXSHGZMLqxXAz9tf/CzsLs6jB1Dbm+qWXXI1f4iY=",
"passwordRevisionDate": null,
"totp": null
},
"attachments": {
"332d98e103d4de5bf813": "2.Km+/MQ3g==|==|/QNlwjvA7klQzrwJDKiQcFbYxIexj0="
},
"attachments2": {
"332d98e103d4de5bf813": {
"fileName": "2.Km+/MQ3g==|==|PFmnkG9TgvPjK/QNlwjvA7klQzrwJDKiQcFbYxIexj0=",
"key": "2.Tzp5QpmPKvB8sd6DWNchUQ==|vQ+/oaQCPySZoA=|QBn3ngdQC7kT0a8qeDZsn+="
}
}
}
```
It should be the same for the mac client. Does it work for you from the web vault?
The error seems to imply that the `key` inside `attachments2` is not being sent for some reason. The individual keys per attachment is a recent change, so I can see how an old attachment that hasn't been migrated to the new model might fail here, but if you re-addded the attachment in the new version then I don't know why it's breaking.
Strange that it can't seem to find the attachment, does the clip icon appear next to the cipher name, and does the filename appear correctly in the attachments list?
Do you get any error when uploading the attachment?
Also, I just noticed that you use the server admin feature, can you try disabling it? We've had problems with it in the past, the next version will come with a proper admin panel.
@dani-garcia commented on GitHub (Dec 24, 2018):
Strange that it can't seem to find the attachment, does the clip icon appear next to the cipher name, and does the filename appear correctly in the attachments list?
Do you get any error when uploading the attachment?
Also, I just noticed that you use the server admin feature, can you try disabling it? We've had problems with it in the past, the next version will come with a proper admin panel.
@AndrewPaglusch commented on GitHub (Dec 24, 2018):
Yes, the paperclip icon is shown next to the entry. The attachment can be downloaded without any problems and the name of the attachment is also displayed correctly. I've just tried uploading a new attachment (web vault) and received no issues/errors.
I'll go ahead and disable that server admin line. Thanks for that info!
@AndrewPaglusch commented on GitHub (Dec 24, 2018):
Yes, the paperclip icon is shown next to the entry. The attachment can be downloaded without any problems and the name of the attachment is also displayed correctly. I've just tried uploading a new attachment (web vault) and received no issues/errors.
I'll go ahead and disable that server admin line. Thanks for that info!
Did that help? I suspect the usage of admin was the root cause here. This is not recommended and will break stuff in strange ways.
@mprasil commented on GitHub (Dec 26, 2018):
Did that help? I suspect the usage of admin was the root cause here. This is [not recommended](https://github.com/dani-garcia/bitwarden_rs#configure-server-administrator) and will break stuff in strange ways.
@AndrewPaglusch commented on GitHub (Dec 26, 2018):
I removed that line and re-created the container. Now I'm getting an error on the Mac client that says "An error has occurred. Attachment doesn't exist" when I try to save this secret.
@AndrewPaglusch commented on GitHub (Dec 26, 2018):
I removed that line and re-created the container. Now I'm getting an error on the Mac client that says "An error has occurred. Attachment doesn't exist" when I try to save this secret.
On the server, the following is logged:
```
bitwarden | [2018-12-26][20:07:11][rocket::rocket][INFO] PUT /api/ciphers/000bfe5c-b808-4ee8-8abc-1ac733687304 application/json; charset=utf-8:
bitwarden | [2018-12-26][20:07:11][_][INFO] Matched: PUT /api/ciphers/<uuid> (put_cipher)
bitwarden | [2018-12-26][20:07:11][bitwarden_rs::api::core::ciphers][ERROR] Attachment doesn't exist
bitwarden | [2018-12-26][20:07:11][_][INFO] Outcome: Success
bitwarden | [2018-12-26][20:07:11][_][INFO] Response succeeded.
```
@AndrewPaglusch commented on GitHub (Dec 26, 2018):
After removing the attachment and syncing the vault, I was able to save edits to the secret without any issues. After re-adding the attachment, the problem came back.
@AndrewPaglusch commented on GitHub (Dec 26, 2018):
After removing the attachment and syncing the vault, I was able to save edits to the secret without any issues. After re-adding the attachment, the problem came back.
Hey, @AndrewPaglusch, I just pushed a change to fix your last error (Attachment doesn't exist) in 6f52104324. Can you test it?
@dani-garcia commented on GitHub (Jan 11, 2019):
Hey, @AndrewPaglusch, I just pushed a change to fix your last error (`Attachment doesn't exist`) in 6f521043245c0e806df5. Can you test it?
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 @AndrewPaglusch on GitHub (Dec 24, 2018).
Environment Information
Docker Image: mprasil/bitwarden:latest (Fully up-to-date. Image ID: 68111df54627)
Bitwarden Mac Client: v1.11.2 on macOS High Sierra
Bitwarden Android Client: v1.21.0 on Android 9 (Path Level Dec 5, 2018)
Docker Compose Configuration
Nginx Configuration
Problem
When trying to save a specific entry on the Mac client, the following error is logged in the docker container:
The following is logged in the Nginx access log:
Nothing is logged to the Nginx error log.
The client displays the following message. The entry is never saved.
This seems similar to this issue: #253
What Works
So far, I have only experienced this issue with this one entry.
What I've Already Tried:
@AndrewPaglusch commented on GitHub (Dec 24, 2018):
I just found something interesting. This secret had a
.jsonfile attached to it. I removed the JSON attachment, re-synced the vault, and then was able to edit the secret without any problems. If I re-add the attachment and then save and re-sync the vault, I am no longer able to make changes to the secret again.Is it possible that the JSON attachment is being parsed? I've just verified that it's valid JSON, if that makes any difference.
@dani-garcia commented on GitHub (Dec 24, 2018):
The file format shouldn't matter, as it would be sent already encrypted, so I imagine it would happen with any file type. Can you check what data is sent from the developer tools (View > Toggle Dev Tools > Network > Select XHR Only)?
I don't have a Mac to test, but when I try to update a cipher with an attachment from the web vault, it sends something like this:
It should be the same for the mac client. Does it work for you from the web vault?
The error seems to imply that the
keyinsideattachments2is not being sent for some reason. The individual keys per attachment is a recent change, so I can see how an old attachment that hasn't been migrated to the new model might fail here, but if you re-addded the attachment in the new version then I don't know why it's breaking.@AndrewPaglusch commented on GitHub (Dec 24, 2018):
Editing this secret fails in the web vault. I get a message saying "An error has occurred. Attachment doesn't exist"
Mac Client JSON Request
I'm not sure what portions of this are sensitive (if any), so I've redacted portions of it. I hope this doesn't make it difficult for you to debug.
Mac Client JSON Reply
@dani-garcia commented on GitHub (Dec 24, 2018):
Strange that it can't seem to find the attachment, does the clip icon appear next to the cipher name, and does the filename appear correctly in the attachments list?
Do you get any error when uploading the attachment?
Also, I just noticed that you use the server admin feature, can you try disabling it? We've had problems with it in the past, the next version will come with a proper admin panel.
@AndrewPaglusch commented on GitHub (Dec 24, 2018):
Yes, the paperclip icon is shown next to the entry. The attachment can be downloaded without any problems and the name of the attachment is also displayed correctly. I've just tried uploading a new attachment (web vault) and received no issues/errors.
I'll go ahead and disable that server admin line. Thanks for that info!
@mprasil commented on GitHub (Dec 26, 2018):
Did that help? I suspect the usage of admin was the root cause here. This is not recommended and will break stuff in strange ways.
@AndrewPaglusch commented on GitHub (Dec 26, 2018):
I removed that line and re-created the container. Now I'm getting an error on the Mac client that says "An error has occurred. Attachment doesn't exist" when I try to save this secret.
On the server, the following is logged:
@mprasil commented on GitHub (Dec 26, 2018):
Can you try and re-add attachment?
@AndrewPaglusch commented on GitHub (Dec 26, 2018):
After removing the attachment and syncing the vault, I was able to save edits to the secret without any issues. After re-adding the attachment, the problem came back.
@dani-garcia commented on GitHub (Jan 11, 2019):
Hey, @AndrewPaglusch, I just pushed a change to fix your last error (
Attachment doesn't exist) in6f52104324. Can you test it?@AndrewPaglusch commented on GitHub (Jan 11, 2019):
This resolved my issue. Thank you very much!