12:06 p.m.
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
12:17 p.m.
Can we have X-OVIRT-SESSIONID header name or any generic term and per ovirt specific
instead of generic java terms?
----- 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
12:40 p.m.
----- 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".
----- 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
>
12:47 p.m.
----- 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.
>
> ----- 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
> >
>
1:18 p.m.
----- 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.)
>
> >
> > ----- 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
> > >
> >
>
1:22 p.m.
----- 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.
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.
>
> >
> > >
> > > ----- 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
> > > >
> > >
> >
>
1:46 p.m.
----- 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
> > > > >
> > > >
> > >
> >
>
1:13 a.m.
----- Original Message -----
From: "Vojtech Szocs" <vszocs(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Juan Antonio Hernandez
Fernandez" <jhernand(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Tuesday, July 15, 2014 9:46:52 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>
> 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
2:31 a.m.
On 07/24/2014 08:13 AM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Vojtech Szocs" <vszocs(a)redhat.com>
> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Juan Antonio Hernandez
Fernandez" <jhernand(a)redhat.com>
> Cc: devel(a)ovirt.org
> Sent: Tuesday, July 15, 2014 9:46:52 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>
>> 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.)
>
?????
Yes, we can change it. But we won't because doing so doesn't have any
benefit.
>>
>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
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.
1:46 p.m.
----- Original Message -----
From: "Juan Hernandez" <jhernand(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Vojtech Szocs"
<vszocs(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Thursday, July 24, 2014 10:31:12 AM
Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires
separate request header
On 07/24/2014 08:13 AM, Alon Bar-Lev wrote:
>
>
> ----- Original Message -----
>> From: "Vojtech Szocs" <vszocs(a)redhat.com>
>> To: "Alon Bar-Lev" <alonbl(a)redhat.com>, "Juan Antonio
Hernandez Fernandez"
>> <jhernand(a)redhat.com>
>> Cc: devel(a)ovirt.org
>> Sent: Tuesday, July 15, 2014 9:46:52 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>
>>> 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.)
>>
>
> ?????
>
Yes, we can change it. But we won't because doing so doesn't have any
benefit.
"we" already explained the benefit.
Please change.
>>>
>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
--
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.
1:26 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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)?
2. Does this change just affect UI plugins or also
other rest api usages?
If it does affect other usages, which one?
Just cookie based operations?
thanks in advance
Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQGcBAEBAgAGBQJTxXJzAAoJEAq0kGAWDrqlEpUL/1DhRE0nqmu8LPF6/nIWn/cD
HXZ05gIFXWGJ/WDpo88xmX4mukYgl0+9tZutwo1LH18uqzeg8LSrgi0XPqwQ2Xvp
lLXLhJzBTrgypx558ub6nS6u0YD4DvHO/6yz5CHVgZC+nHQerd5BqxOyexP36JZl
JZCL0pygK35e5Tx0miG5Zrvd1Tpoq+UD1UCMOCy6FYVHk9Wio4ezKYTx7DwglTX/
wL2HxHfrLNVq3lFTcl/TMGxS+dfhv6DxqHn1CtOsV2OSouecvpSlSdgzmnjgElib
Ll/zKCXbxS8+P/9yj3EviZzqjLItqmKR+rIWW67Vm+Pky+g+wf9m1lA+leYkJj1r
B2CXOtgIUycc4D0SRJXGMjMnsGrrgNTIUFh9lqq77XZw+dxeWuV+zMnPQ1SU5kPB
FEadlVTwEWHEBrWtnin08F6NXzCgIQ1VBMgbR9BaV9UR2220BRBR2ocTycohiAbx
BOL3k6NhU83JzybFtILrR8MVK7uEPFD7M+sby0j1qw==
=QbPl
-----END PGP SIGNATURE-----
1:58 p.m.
----- 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
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.)
thanks in advance
Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQGcBAEBAgAGBQJTxXJzAAoJEAq0kGAWDrqlEpUL/1DhRE0nqmu8LPF6/nIWn/cD
HXZ05gIFXWGJ/WDpo88xmX4mukYgl0+9tZutwo1LH18uqzeg8LSrgi0XPqwQ2Xvp
lLXLhJzBTrgypx558ub6nS6u0YD4DvHO/6yz5CHVgZC+nHQerd5BqxOyexP36JZl
JZCL0pygK35e5Tx0miG5Zrvd1Tpoq+UD1UCMOCy6FYVHk9Wio4ezKYTx7DwglTX/
wL2HxHfrLNVq3lFTcl/TMGxS+dfhv6DxqHn1CtOsV2OSouecvpSlSdgzmnjgElib
Ll/zKCXbxS8+P/9yj3EviZzqjLItqmKR+rIWW67Vm+Pky+g+wf9m1lA+leYkJj1r
B2CXOtgIUycc4D0SRJXGMjMnsGrrgNTIUFh9lqq77XZw+dxeWuV+zMnPQ1SU5kPB
FEadlVTwEWHEBrWtnin08F6NXzCgIQ1VBMgbR9BaV9UR2220BRBR2ocTycohiAbx
BOL3k6NhU83JzybFtILrR8MVK7uEPFD7M+sby0j1qw==
=QbPl
-----END PGP SIGNATURE-----
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2: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.
3586
days inactive
3597
days old
12 comments
4 participants
participants (4)
-
Alon Bar-Lev -
Juan Hernandez -
Sven Kieske -
Vojtech Szocs