Searched hist:"29 aab242f2d35891bd808e057e33b328989836d3" (Results 1 – 4 of 4) sorted by relevance
| /openbmc/bmcweb/include/ |
| H A D | cookies.hpp | 29aab242f2d35891bd808e057e33b328989836d3 Wed Jun 12 14:28:47 CDT 2024 Paul Fertser <fercerpav@gmail.com> Send cookies to webui-vue from Sessions POST
Using Redfish-standard X-Auth-Token authentication is less secure
(against injected JS code) compared to an HttpOnly (not available to the
JS VM) SESSION cookie. Currently webui-vue authenticates connections to
WebSocket URIs not only by a JS-accessible token (passed as subprotocol
when upgrading to WS) but also via a SESSION cookie (even though it is
not subject to CORS policy).
To allow WebSocket-based functionality (IP KVM, SOL, VM) after creating
a Session object send a set of cookies instead of the X-Auth-Token
header if the request was made by webui-vue (detected by presence of
"X-Requested-With" header).
Factor out cookie setting and clearing functions and use explicit Path=/
attribute as the cookies are valid for the whole server, not just the
path of the endpoint they were created by.
Not specifying Path was functional for /login endpoint because
https://www.rfc-editor.org/rfc/rfc6265#section-5.3 point 7 for this case
says "set the cookie's path to the default-path of the request-uri" and
https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4 tells how to
compute the default path. Basically, it was a "happy coincidence" that
/login defaults to / for the Path, if it was /openbmc/login then the
cookies would have been set to Path=/openbmc and not work at all for
/redfish/v1 endpoints.
Tested: Redfish-Service-Validator doesn't see a difference. Runtime
testing logging in via Sessions endpoint, getting data, using websockets
and logging out against webui-vue with a corresponding change while
carefully observing Request and Response headers. Creating a session
with curl without the special header shows just X-Auth-Token and no
cookies in the response.
Change-Id: I0b1774e586671874bb79f115e9cddf194f9ea653
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
| H A D | authentication.hpp | diff 29aab242f2d35891bd808e057e33b328989836d3 Wed Jun 12 14:28:47 CDT 2024 Paul Fertser <fercerpav@gmail.com> Send cookies to webui-vue from Sessions POST
Using Redfish-standard X-Auth-Token authentication is less secure
(against injected JS code) compared to an HttpOnly (not available to the
JS VM) SESSION cookie. Currently webui-vue authenticates connections to
WebSocket URIs not only by a JS-accessible token (passed as subprotocol
when upgrading to WS) but also via a SESSION cookie (even though it is
not subject to CORS policy).
To allow WebSocket-based functionality (IP KVM, SOL, VM) after creating
a Session object send a set of cookies instead of the X-Auth-Token
header if the request was made by webui-vue (detected by presence of
"X-Requested-With" header).
Factor out cookie setting and clearing functions and use explicit Path=/
attribute as the cookies are valid for the whole server, not just the
path of the endpoint they were created by.
Not specifying Path was functional for /login endpoint because
https://www.rfc-editor.org/rfc/rfc6265#section-5.3 point 7 for this case
says "set the cookie's path to the default-path of the request-uri" and
https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4 tells how to
compute the default path. Basically, it was a "happy coincidence" that
/login defaults to / for the Path, if it was /openbmc/login then the
cookies would have been set to Path=/openbmc and not work at all for
/redfish/v1 endpoints.
Tested: Redfish-Service-Validator doesn't see a difference. Runtime
testing logging in via Sessions endpoint, getting data, using websockets
and logging out against webui-vue with a corresponding change while
carefully observing Request and Response headers. Creating a session
with curl without the special header shows just X-Auth-Token and no
cookies in the response.
Change-Id: I0b1774e586671874bb79f115e9cddf194f9ea653
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
| H A D | login_routes.hpp | diff 29aab242f2d35891bd808e057e33b328989836d3 Wed Jun 12 14:28:47 CDT 2024 Paul Fertser <fercerpav@gmail.com> Send cookies to webui-vue from Sessions POST
Using Redfish-standard X-Auth-Token authentication is less secure
(against injected JS code) compared to an HttpOnly (not available to the
JS VM) SESSION cookie. Currently webui-vue authenticates connections to
WebSocket URIs not only by a JS-accessible token (passed as subprotocol
when upgrading to WS) but also via a SESSION cookie (even though it is
not subject to CORS policy).
To allow WebSocket-based functionality (IP KVM, SOL, VM) after creating
a Session object send a set of cookies instead of the X-Auth-Token
header if the request was made by webui-vue (detected by presence of
"X-Requested-With" header).
Factor out cookie setting and clearing functions and use explicit Path=/
attribute as the cookies are valid for the whole server, not just the
path of the endpoint they were created by.
Not specifying Path was functional for /login endpoint because
https://www.rfc-editor.org/rfc/rfc6265#section-5.3 point 7 for this case
says "set the cookie's path to the default-path of the request-uri" and
https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4 tells how to
compute the default path. Basically, it was a "happy coincidence" that
/login defaults to / for the Path, if it was /openbmc/login then the
cookies would have been set to Path=/openbmc and not work at all for
/redfish/v1 endpoints.
Tested: Redfish-Service-Validator doesn't see a difference. Runtime
testing logging in via Sessions endpoint, getting data, using websockets
and logging out against webui-vue with a corresponding change while
carefully observing Request and Response headers. Creating a session
with curl without the special header shows just X-Auth-Token and no
cookies in the response.
Change-Id: I0b1774e586671874bb79f115e9cddf194f9ea653
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|
| /openbmc/bmcweb/redfish-core/lib/ |
| H A D | redfish_sessions.hpp | diff 29aab242f2d35891bd808e057e33b328989836d3 Wed Jun 12 14:28:47 CDT 2024 Paul Fertser <fercerpav@gmail.com> Send cookies to webui-vue from Sessions POST
Using Redfish-standard X-Auth-Token authentication is less secure
(against injected JS code) compared to an HttpOnly (not available to the
JS VM) SESSION cookie. Currently webui-vue authenticates connections to
WebSocket URIs not only by a JS-accessible token (passed as subprotocol
when upgrading to WS) but also via a SESSION cookie (even though it is
not subject to CORS policy).
To allow WebSocket-based functionality (IP KVM, SOL, VM) after creating
a Session object send a set of cookies instead of the X-Auth-Token
header if the request was made by webui-vue (detected by presence of
"X-Requested-With" header).
Factor out cookie setting and clearing functions and use explicit Path=/
attribute as the cookies are valid for the whole server, not just the
path of the endpoint they were created by.
Not specifying Path was functional for /login endpoint because
https://www.rfc-editor.org/rfc/rfc6265#section-5.3 point 7 for this case
says "set the cookie's path to the default-path of the request-uri" and
https://www.rfc-editor.org/rfc/rfc6265#section-5.1.4 tells how to
compute the default path. Basically, it was a "happy coincidence" that
/login defaults to / for the Path, if it was /openbmc/login then the
cookies would have been set to Path=/openbmc and not work at all for
/redfish/v1 endpoints.
Tested: Redfish-Service-Validator doesn't see a difference. Runtime
testing logging in via Sessions endpoint, getting data, using websockets
and logging out against webui-vue with a corresponding change while
carefully observing Request and Response headers. Creating a session
with curl without the special header shows just X-Auth-Token and no
cookies in the response.
Change-Id: I0b1774e586671874bb79f115e9cddf194f9ea653
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
|