10:20 a.m.
On 07/15/2014 08:58 PM, Vojtech Szocs wrote:
----- Original Message -----
> From: "Sven Kieske" <svenkieske(a)gmail.com> To: devel(a)ovirt.org
> Sent: Tuesday, July 15, 2014 8:26:59 PM Subject: Re:
> [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now
> requires separate request header
>
Just a few questions from someone who relies on the rest api:
Background: I use rest not for UI plugins but for general
management stuff (basically all ovirt operations which are possible
via rest) I don't use the cookie based session management but pure
rest (stateless).
Questions: 1. Will stateless rest sessions always be supported or
do you plan to change this in the future to just allow cookie based
access (so no real rest api, as it's not stateless anymore)?
> My understanding is that REST API's session management feature is
> something on top of (stateless) REST / HTTP concept, so I'd say
> that "stateless" approach (sending user credentials with each
> request, without using any session) should always be supported.
Stateless access to the RESTAPI is and will be supported. We don't
have any plan to remove it.
2. Does this change just affect UI plugins or also other rest api
usages?
> It just affects UI plugins deployed on Engine 3.5 or later, which
> are talking to Engine via session ID provided by
> "RestApiSessionAcquired" hook.
If it does affect other usages, which one? Just cookie based
operations?
> None of the above :)
> In general, when you ask REST API to create session ("Prefer:
> persistent-auth" header), you can also tell the preference
> whether you want to CSRF-protect it ("Prefer: csrf-protection")
> or not.
> If a REST API session is marked as CSRF-protected, in addition to
> sending JSESSIONID cookie, you must also send JSESSIONID _header_
> with same value.
> (WebAdmin UI plugin infra acquires CSRF-protected REST API
> session for all UI plugins.)
What Vojtech says is correct, and I would like to add some details.
First important thing to take into account is that the CSRF protection
mechanism will be completely disabled by default in 3.5. In order to
enable it the CSRFProtection parameter has to be changed to true (the
default is false):
# engine-config -s CSRFProtection=true
# service ovirt-engine restart
Second important thing is that when CSRFProtection is enabled the
caller still *needs* to enable it in a per-session based, adding the
"Prefer: csrf-protection" header to the first request of the session.
If this header isn't provided then the CSRF protection is disabled for
that session. In 3.5 webadmin will always request CSRF protection, so
UI plugins that use the RESTAPI session provided by webadmin will need
to send the JSESSIONID header.
If you have UI plugins that use the RESTAPI session and can't be
modified to send the JSESSIONID header then you will need to keep the
CSRF protection disabled (CSRFProtection=false).
Third important thing is that the CSRF protection doesn't affect at
all callers that don't use sessions. Also it doesn't affect at all
callers that use sessions but don't send the "Prefer: csrf-protection"
header.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.