----- Original Message ----- > From: "Vojtech Szocs" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: [email protected], "Oved Ourfalli" <[email protected]>, "René Koch" > <[email protected]> > 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" <[email protected]> > > To: "Vojtech Szocs" <[email protected]> > > Cc: [email protected], "Oved Ourfalli" <[email protected]>, "René Koch" > > <[email protected]> > > 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" <[email protected]> > > > To: [email protected] > > > Cc: "Oved Ourfalli" <[email protected]>, "René Koch" <[email protected]> > > > 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 > > > [email protected] > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
