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

[Martin Mucha]

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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Vojtech Szocs]

- Original Message -
> From: "Martin Sivak" <msi...@redhat.com>
> To: "Vojtech Szocs" <vsz...@redhat.com>
> Cc: "devel" <devel@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 " (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 <vsz...@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@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> 
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Martin Mucha]

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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Martin Sivak]

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  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@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

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

[Vojtech Szocs]

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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel