Bug #16774
closed
keep-web needs to return user-visible errors
Added by Peter Amstutz over 4 years ago.
Updated almost 4 years ago.
Estimated time:
(Total: 0.00 h)
Release relationship:
Auto
Description
I tried to download a file from keep-web with an invalid token. In the browser, without using developer tools, there is no feedback to the user why it didn't work.
- There is no error page. For any 4xx or 5xx error it should return a minimal error page
- Despite the error is actually that the token is invalid, it returns 404 instead of 401
- A 404 can mean either that an item doesn't exist, or that the user doesn't have permission to see it. The error text should reflect that.
Sort of related, I also realized that if keep-web sets a cookie with the API token, there's no way for the user to clear that cookie without going into browser settings.
- Description updated (diff)
- Description updated (diff)
- Related to Story #16444: Improved error detection/reporting added
- Target version changed from 2020-09-23 Sprint to 2020-10-07 Sprint
- Target version changed from 2020-10-07 Sprint to 2020-10-21 Sprint
- Target version deleted (
2020-10-21 Sprint)
- Target version set to 2020-11-04 Sprint
- Subject changed from keep-web should return better errors to keep-web needs to return user-visible errors
- Description updated (diff)
- Description updated (diff)
- Assigned To set to Peter Amstutz
- Target version changed from 2020-11-04 Sprint to 2020-11-18
- Target version changed from 2020-11-18 to 2020-12-02 Sprint
Might be worth using XML encoder here, in case error messages/paths have "<" chars etc.
review at aa1c0f3049f7b78e7590dde868b915bef9a7ebbe
services/keep-web/handler.go:
- Maybe I'm too picky here, but any reason to have "\n" in the errors? Would this cause issues on non-Unix systems that use "\r\n" like Windows? also reading RFC 2046 https://www.ietf.org/rfc/rfc2046.txt section 4.1.1 says: "The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden."
This is for Content-Type: text/plain, but I don't know what Content-Type we are using in the errors.
- as a separate note, I also notice an extra "\n" on the check... as in c.Check(body, check.Equals, notFoundMessage+"\n") any reason why is there?
services/keep-web/s3_test.go:
I noticed the checks are comparing the body only. It will be good to add a comparison of the statusCode too.. since clients could be only checking that.
- Status changed from New to In Progress
Nico César wrote:
review at aa1c0f3049f7b78e7590dde868b915bef9a7ebbe
services/keep-web/handler.go:
- Maybe I'm too picky here, but any reason to have "\n" in the errors? Would this cause issues on non-Unix systems that use "\r\n" like Windows? also reading RFC 2046 https://www.ietf.org/rfc/rfc2046.txt section 4.1.1 says: "The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden."
This is for Content-Type: text/plain, but I don't know what Content-Type we are using in the errors.
Sure. I don't think this is a problem in practice but I fixed it anyway.
- as a separate note, I also notice an extra "\n" on the check... as in c.Check(body, check.Equals, notFoundMessage+"\n") any reason why is there?
The responses use http.Error() which calls Fprintln() which adds a newline to the end of the message:
https://golang.org/src/net/http/server.go?s=63178:63230#L2041
So the string comparison has to add the newline added by Fprintln().
services/keep-web/s3_test.go:
I noticed the checks are comparing the body only. It will be good to add a comparison of the statusCode too.. since clients could be only checking that.
I added checks for the codes in addition to the error messages.
16774-keep-web-errors @ 7d94b1ed55350c01689ad048aee961b261263dd9
developer-run-tests: #2196
review @ 7d94b1ed55350c01689ad048aee961b261263dd9
I think that \n or \r\n should be avoided from the message at all leaving as constants since 401 status code will come with them message:
const notFoundMessage = "The requested path was not found, or you do not have permission to access it."
const unauthorizedMessage = "A valid Arvados token must be provided to access this resource."
But either way is good to merge.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF