1:43 p.m.
Hi,
in oVirt 4.0 the RestApiSessionAcquired event will be replaced
with API to create authenticated requests for Engine services.
Using REST API persistent session mechanism where UI acquires
a single session to be shared by all UI plugins led us to many
problems in the past, typically observed by end users as "Auth
Required" browser popups.
The new API proposed by [1] creates XMLHttpRequest object with
following properties:
* sets "Authorization: Bearer xxx" header before sending
* logs request and response details (enabled via API option)
[1] https://gerrit.ovirt.org/#/c/49278/
Example:
var xhr = api.createEngineHttpRequest();
xhr.open('GET', 'http://example.com/ovirt-engine/api', true);
xhr.setRequestHeader('Accept', 'application/json');
xhr.send(null);
Since REST API persistent session mechanism currently relies
on cookie (JSESSIONID), individual UI plugins should not try
to create a REST session on their own to avoid any clashes.
Regards,
Vojtech
11:14 a.m.
Hi,
that is a nice improvement, but I have one question.. how are we going
to use this when we have no direct access to the xhr object? jQuery
and Angular abstractions come to my mind..
Martin
On Fri, Jan 22, 2016 at 1:43 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
Hi,
in oVirt 4.0 the RestApiSessionAcquired event will be replaced
with API to create authenticated requests for Engine services.
Using REST API persistent session mechanism where UI acquires
a single session to be shared by all UI plugins led us to many
problems in the past, typically observed by end users as "Auth
Required" browser popups.
The new API proposed by [1] creates XMLHttpRequest object with
following properties:
* sets "Authorization: Bearer xxx" header before sending
* logs request and response details (enabled via API option)
[1] https://gerrit.ovirt.org/#/c/49278/
Example:
var xhr = api.createEngineHttpRequest();
xhr.open('GET', 'http://example.com/ovirt-engine/api', true);
xhr.setRequestHeader('Accept', 'application/json');
xhr.send(null);
Since REST API persistent session mechanism currently relies
on cookie (JSESSIONID), individual UI plugins should not try
to create a REST session on their own to avoid any clashes.
Regards,
Vojtech
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:54 p.m.
----- Original Message -----
From: "Martin Sivak" <msivak(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "devel" <devel(a)ovirt.org>
Sent: Monday, January 25, 2016 11:14:52 AM
Subject: Re: [ovirt-devel] [UI plugins] replacing RestApiSessionAcquired event
Hi,
that is a nice improvement, but I have one question.. how are we going
to use this when we have no direct access to the xhr object? jQuery
and Angular abstractions come to my mind..
Hi Martin, great question!
Looking at differences between standard XMLHttpRequest, jqXHR (jQuery)
and $http (Angular), the jqXHR [1] is generally designed as superset
of standard XHR (with some API differences) while $http [2] generally
hides the actual XHR object behind its own API.
[1] http://api.jquery.com/jQuery.ajax/#jqXHR
[2] https://docs.angularjs.org/api/ng/service/$http
To support all of these cases (as well as other XHR abstractions),
methods introduced into oVirt UI plugin API should be fine-grained.
Example - XMLHttpRequest:
var xhr = new XMLHttpRequest();
xhr.open('GET', 'http://example.com/ovirt-engine/api');
xhr.setRequestHeader('Authorization', api.bearerAuthHeader());
xhr.setRequestHeader('Accept', 'application/json');
xhr.addEventListener('load', function () {
// response loaded OK, parse JSON data
var data = JSON.parse(this.responseText);
});
xhr.send(null);
Example - jQuery:
var request = $.ajax({
method: 'GET',
url: 'http://example.com/ovirt-engine/api',
dataType: 'json',
headers: {
'Authorization': api.bearerAuthHeader(),
'Accept': 'application/json'
}
});
request.then(function (data) {
// JSON data already parsed (dataType was set to json)
});
Example - Angular:
var request = $http({
method: 'GET',
url: 'http://example.com/ovirt-engine/api',
headers: {
'Authorization': api.bearerAuthHeader(),
'Accept': 'application/json'
}
});
request.then(function (data) {
// JSON data already parsed (default Angular transforms)
});
Even though $.ajax and $http functions share a similar API, objects
they return are different (aside from supporting standard promise-
like callbacks such as "then").
Above examples just use "api.bearerAuthHeader" method that returns
"Bearer <SSO_TOKEN>" (the value of "Authorization" HTTP
header).
With different HTTP request APIs out there, I feel like the small,
fine-grained methods are really the only feasible option.
(Another approach would be to force UI plugin authors to utilize
our own API to make HTTP requests, but that would essentially lead
into scenarios where a UI plugin written in Angular would have to
avoid using $http, etc.)
Regards,
Vojtech
Martin
On Fri, Jan 22, 2016 at 1:43 PM, Vojtech Szocs <vszocs(a)redhat.com> wrote:
> Hi,
>
> in oVirt 4.0 the RestApiSessionAcquired event will be replaced
> with API to create authenticated requests for Engine services.
>
> Using REST API persistent session mechanism where UI acquires
> a single session to be shared by all UI plugins led us to many
> problems in the past, typically observed by end users as "Auth
> Required" browser popups.
>
> The new API proposed by [1] creates XMLHttpRequest object with
> following properties:
> * sets "Authorization: Bearer xxx" header before sending
> * logs request and response details (enabled via API option)
>
> [1] https://gerrit.ovirt.org/#/c/49278/
>
> Example:
>
> var xhr = api.createEngineHttpRequest();
> xhr.open('GET', 'http://example.com/ovirt-engine/api', true);
> xhr.setRequestHeader('Accept', 'application/json');
> xhr.send(null);
>
> Since REST API persistent session mechanism currently relies
> on cookie (JSESSIONID), individual UI plugins should not try
> to create a REST session on their own to avoid any clashes.
>
> Regards,
> Vojtech
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
7:45 p.m.
Hi,
I got another bug about missing constructor:
public …(P parameters, EngineContext engineContext) {
super(parameters, engineContext);
}
so I looked into:
org.ovirt.engine.core.bll.QueriesCommandBase
and it seems, that sole 'problem' is with initialization of user in @PostConstruct
method. It seems, that we can easily set all those fields via setters, and user
initialization can be done later, for example before calling executeQueryCommand in:
org.ovirt.engine.core.bll.QueriesCommandBase#executeCommand
doing this will move us closer to CDI and avoid errors because of forgotten constructor.
Is there a obstacle blocking us from doing this?
thanks,
Mar.
9:58 a.m.
sorry, I made a mistake this is not a reply to this subject.
M.
----- Original Message -----
Hi,
I got another bug about missing constructor:
public …(P parameters, EngineContext engineContext) {
super(parameters, engineContext);
}
so I looked into:
org.ovirt.engine.core.bll.QueriesCommandBase
and it seems, that sole 'problem' is with initialization of user in
@PostConstruct method. It seems, that we can easily set all those fields via
setters, and user initialization can be done later, for example before
calling executeQueryCommand in:
org.ovirt.engine.core.bll.QueriesCommandBase#executeCommand
doing this will move us closer to CDI and avoid errors because of forgotten
constructor. Is there a obstacle blocking us from doing this?
thanks,
Mar.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
3006
days inactive
3010
days old
4 comments
3 participants
participants (3)
-
Martin Mucha -
Martin Sivak -
Vojtech Szocs