[ovirt-devel] [UI plugins] replacing RestApiSessionAcquired event

[Vojtech Szocs]

----- Original Message -----
> From: "Martin Sivak" <msivak at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "devel" <devel at 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 at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>