tree 6c983374ef2a778b6dbb0c8c90db219e0a029d6d
parent 92903bd47b8d2e2b2e777d1ba61871a3b54fefd4
author Ed Tanous <edtanous@google.com> 1652307839 -0700
committer Ed Tanous <ed@tanous.net> 1654539554 +0000

Fix www-authenticate behavior

bmcweb is in a weird position where, on the one hand, we would like to
support Redfish to the specification, while also supporting a secure
webui.  For better or worse, the webui can't currently use non-cookie
auth because of the impacts to things outside of Redfish like
websockets.

This has lead to some odd code in bmcweb that tries to "detect" whether
the browser is present, so we don't accidentally pop up the basic auth
window if a user happens to get logged out on an xhr request.  Basic
auth in a browser actually causes CSRF vulnerabilities, as the browser
caches the credentials, so we don't want to make that auth method
available at all.

Previously, this detection was based on the presence of the user-agent
header, but in the years since this code was originally written, a
majority of implementations have moved to sending a user-agent by
default, which makes this check pretty much useless for its purpose.  To
work around that, this patchset relies on the X-Requested-With header,
to determine if a json payload request was done by xhr.  In theory, all
browsers will set this header when doing xhr requests, so this should
provide a "more correct" solution to this issue.

Background:
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
"X-Requested-With Mainly used to identify Ajax requests (most JavaScript
frameworks send this field with value of XMLHttpRequest)"

Tested:
curl -vvvv --insecure  https://192.168.7.2/redfish/v1/SessionService/Sessions
Now returns a WWW-Authenticate header

Redfish-protocol-validator now passes 7 more tests from the
RESP_HEADERS_WWW_AUTHENTICATE category.

Launched webui-vue and logged in.  Responses in network tab appear to
work, and data populates the page as expected.
Used curl to delete redfish session from store with
DELETE /redfish/v1/SessionService/Sessions/<SessionId>
Then clicked an element on the webui, page forwarded to login page as
expected.

Opened https://localhost:8000/redfish/v1/CertificateService in a
browser, and observed that page forwarded to the login page as it
should.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: I60345caa41e520c23fe57792bf2e8c16ef144a7a