----- Original Message -----
From: "Alon Bar-Lev" <alonbl(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: devel(a)ovirt.org, "Oved Ourfalli" <ovedo(a)redhat.com>
Sent: Tuesday, July 15, 2014 8:22:06 PM
Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires
separate request header
----- Original Message -----
> From: "Vojtech Szocs" <vszocs(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Cc: devel(a)ovirt.org, "Oved Ourfalli" <ovedo(a)redhat.com>
> Sent: Tuesday, July 15, 2014 9:18:44 PM
> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID
> now requires separate request header
>
>
>
> ----- Original Message -----
> > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > To: "Vojtech Szocs" <vszocs(a)redhat.com>
> > Cc: devel(a)ovirt.org, "Oved Ourfalli" <ovedo(a)redhat.com>,
"René Koch"
> > <r.koch(a)ovido.at>
> > Sent: Tuesday, July 15, 2014 7:47:35 PM
> > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via
> > JSESSIONID
> > now requires separate request header
> >
> >
> >
> > ----- Original Message -----
> > > From: "Vojtech Szocs" <vszocs(a)redhat.com>
> > > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Cc: devel(a)ovirt.org, "Oved Ourfalli" <ovedo(a)redhat.com>,
"René Koch"
> > > <r.koch(a)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(a)redhat.com>
> > > > To: "Vojtech Szocs" <vszocs(a)redhat.com>
> > > > Cc: devel(a)ovirt.org, "Oved Ourfalli"
<ovedo(a)redhat.com>, "René Koch"
> > > > <r.koch(a)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-con...
> > >
> > > 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.
>
> Yes, we could also change it now, because JSESSIONID header was
> introduced only recently by
http://gerrit.ovirt.org/#/c/29681/
>
> However I think this is not really "Engine session ID", but rather
> "Java webapp session ID" - AFAIK, real Engine session ID is stored
> inside Java webapp session attribute - see SessionConstants
> HTTP_SESSION_ENGINE_SESSION_ID_KEY ("ovirt_aaa_engineSessionId").
>
> But we can consider real Engine session ID as impl. detail, so we
> can rename JSESSIONID to OVIRT-SESSIONID or similar.
>
> As for the cookie name, I'm not aware of any way to change it in
> JBoss. I think that even Java servlet spec says it must be called
> JSESSIONID. (But then again, in future I'd like to avoid using that
> cookie altogether, in favor of using custom OVIRT-SESSIONID header.)
>
it is not important what session id it is... it can be the jboss now and
other later, what important is that we do not change the interface in
future, so that the session id whatever it may be is set within header that
is forward compatible.
I agree.
@Juan, can we change JSESSIONID header to OVIRT-SESSIONID or similar,
in scope of REST API webapp?
(Also to be used in future instead of JSESSIONID cookie, to associate
client request with REST API / Engine session.)
the fact that we have a cookie is nice, may have some value (or not...), but
cookie is set by server and sent by client automatically, so naming is not
important.
Right, web browsers take care of cookies automatically and other
clients can prefer to use custom header like OVIRT-SESSIONID,
if they want.
> >
> > >
> > > >
> > > > ----- Original Message -----
> > > > > From: "Vojtech Szocs" <vszocs(a)redhat.com>
> > > > > To: devel(a)ovirt.org
> > > > > Cc: "Oved Ourfalli" <ovedo(a)redhat.com>,
"René Koch"
> > > > > <r.koch(a)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(a)ovirt.org
> > > > >
http://lists.ovirt.org/mailman/listinfo/devel
> > > > >
> > > >
> > >
> >
>