[ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
Vojtech Szocs
vszocs at redhat.com
Tue Jul 15 17:40:30 UTC 2014
----- Original Message -----
> From: "Alon Bar-Lev" <alonbl at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: devel at ovirt.org, "Oved Ourfalli" <ovedo at redhat.com>, "René Koch" <r.koch at ovido.at>
> Sent: Tuesday, July 15, 2014 7:17:40 PM
> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
>
>
> Can we have X-OVIRT-SESSIONID header name or any generic term and per ovirt
> specific instead of generic java terms?
Good question. In general I agree, JavaEE's default "JSESSIONID" naming
convention for custom header (or cookie) is not very meaningful in multi
app deployment.
However, I'd rather avoid "X-" prefix [1].
[1] http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions
Currently, it is the "JSESSIONID" cookie which maps to the session.
Currently, "JSESSIONID" custom header is only for CSRF-protection,
i.e. to be compared with cookie value (cookie is still required in
order to reuse existing session).
AFAIK, Juan plans to support passing session ID via custom HTTP
header, as an alternative to passing session ID via cookie. When
this gets done, the custom HTTP header should be named something
like "OVIRT-SESSIONID".
>
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: devel at ovirt.org
> > Cc: "Oved Ourfalli" <ovedo at redhat.com>, "René Koch" <r.koch at ovido.at>
> > Sent: Tuesday, July 15, 2014 8:06:19 PM
> > Subject: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now
> > requires separate request header
> >
> > Hi guys,
> >
> > please be advised, patch for master [1] as well as ovirt-engine-3.5 [2]
> > branch was merged recently. This patch enables CSRF (Cross-Site Request
> > Forgery) protection for REST API session acquired by WebAdmin UI plugin
> > infrastructure.
> >
> > If you maintain UI plugin(s) and utilize "RestApiSessionAcquired" event
> > handler function, i.e. your UI plugin (JavaScript) calls Engine directly
> > or you pass the session ID to some other system which calls Engine, make
> > sure that any request to Engine contains both:
> >
> > * JSESSIONID cookie (as today)
> > * JSESSIONID request header (this is new)
> >
> > For CSRF-protected session [3], REST API backend compares these values
> > and if not successful, it responds with HTTP 403 (Forbidden) which will
> > break the communication with Engine.
> >
> > As mentioned above, this applies to all UI plugins deployed on Engine
> > WebAdmin version 3.5 and later.
> >
> > In order to stay compatible with older (unpatched) UI plugins, we could
> > introduce some Engine config parameter to control whether the REST API
> > session for UI plugins should use CSRF protection or not.
> >
> > [1] http://gerrit.ovirt.org/#/c/29682/
> > [2] http://gerrit.ovirt.org/#/c/29850/
> > [3] details in commit message of http://gerrit.ovirt.org/#/c/29849/
> >
> > Regards,
> > Vojtech
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
More information about the Devel
mailing list