[ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header

[Alon Bar-Lev]

----- Original Message -----
> From: "Vojtech Szocs" <vszocs at redhat.com>
> To: "Alon Bar-Lev" <alonbl 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 8:40:30 PM
> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
> 
> 
> 
> ----- 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".

I do not see any reason why not to use this (or any other non JSESSIONID) name for header now.

> 
> > 
> > ----- 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
> > > 
> > 
>