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
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@redhat.com> To: devel@ovirt.org Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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-conven... 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@redhat.com> To: devel@ovirt.org Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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-conven...
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@redhat.com> To: devel@ovirt.org Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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-conven...
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@redhat.com> To: devel@ovirt.org Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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-conven...
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@redhat.com> To: devel@ovirt.org Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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-conven...
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@redhat.com> To: devel@ovirt.org Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com> Cc: devel@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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-conven...
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@redhat.com> > To: devel@ovirt.org > Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" > <r.koch@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel >
On 07/24/2014 08:13 AM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com> Cc: devel@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> > To: "Vojtech Szocs" <vszocs@redhat.com> > Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René > Koch" > <r.koch@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-conven...
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@redhat.com> >> To: devel@ovirt.org >> Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" >> <r.koch@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@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.
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Juan Antonio Hernandez Fernandez" <jhernand@redhat.com> Cc: devel@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@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@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" <r.koch@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@redhat.com> > To: "Alon Bar-Lev" <alonbl@redhat.com> > Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" > <r.koch@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@redhat.com> >> To: "Vojtech Szocs" <vszocs@redhat.com> >> Cc: devel@ovirt.org, "Oved Ourfalli" <ovedo@redhat.com>, "René >> Koch" >> <r.koch@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-conven... > > 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@redhat.com> >>> To: devel@ovirt.org >>> Cc: "Oved Ourfalli" <ovedo@redhat.com>, "René Koch" >>> <r.koch@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@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.
-----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-----
----- Original Message -----
From: "Sven Kieske" <svenkieske@gmail.com> To: devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 07/15/2014 08:58 PM, Vojtech Szocs wrote:
----- Original Message -----
From: "Sven Kieske" <svenkieske@gmail.com> To: devel@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.
participants (4)
-
Alon Bar-Lev -
Juan Hernandez -
Sven Kieske -
Vojtech Szocs