Bug 894687 - [rhevm] - Webadmin - Web Admin tries to acquire REST API session using UI user credentials ("Authentication Required" browser popup)
[rhevm] - Webadmin - Web Admin tries to acquire REST API session using UI use...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.2.0
Unspecified Unspecified
unspecified Severity high
: ---
: 3.2.0
Assigned To: vszocs
David Botzer
ux
: Regression
Depends On:
Blocks: 948448
  Show dependency treegraph
 
Reported: 2013-01-13 03:22 EST by David Botzer
Modified: 2015-09-22 09 EDT (History)
14 users (show)

See Also:
Fixed In Version: sf16
Doc Type: Release Note
Doc Text:
Previously the web browser sent HTTP Authorization headers for all requests to a given origin after the header has already been set for the initial request. This meant the user interface plugin infrastructure acquired a REST API session using web administration portal user credentials including domain and password information, and the session was kept alive until the user signed out of the administration portal. To work around this issue, all user interface plugins now receive a single shared session ID based on the web administration portal user login credentials. This session times out after six hours, and the administration portal will not attempt to keep this session alive using periodic heartbeat requests. The plugin is in charge of keeping its session alive, and if no plugin interacts with the REST API session via the provided ID for more than six hours, the session will time out.
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sgrinber: Triaged+


Attachments (Terms of Use)
auth-popup (132.79 KB, image/png)
2013-01-13 03:49 EST, David Botzer
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 14411 None None None Never

  None (edit)
Description David Botzer 2013-01-13 03:22:51 EST
Description of problem:
I keep getting in webadmin popup "Authentication Required"
"The site says: Engine"

Version-Release number of selected component (if applicable):
3.2/sf3

How reproducible:
always

Steps to Reproduce:
1.Install rhevm+dwh+reports
2.While working with Webadmin
  
Actual results:
"Authentication Required" browser popup

Expected results:
Should not display popup window

Additional info:
Vojtech Szocs wrote:
----------------------
the "Authentication Required" browser popup is indeed related to Engine REST API integration in UI Plugins infrastructure.

Upon each successful (Web Admin UI) login, UI Plugins infrastructure tries to acquire new REST API session [1] via HTTP GET to /api, passing 'Prefer:persistent-auth' header along with user/domain/password information via HTTP basic auth ('Authorization') header. In other words, Web Admin tries to acquire REST API session using UI user credentials. While the user stays authenticated in Web Admin UI, UI Plugins infrastructure sends periodic heartbeat requests to keep the acquired REST API session alive, until the user signs out of Web Admin.

If you see the "Authentication Required" browser popup, it means that REST API rejected the request as unauthorized (wrong user credentials), which is really strange. David, are there any steps to reproduce this problem?

Some facts about "Authentication Required" browser popup:
- triggered on any response (including AJAX/XHR) with status code 401 (Unauthorized)
- can NOT be disabled via JavaScript, it's part of standard browser behavior [2]

To disable "Authentication Required" browser popup on failed request, REST API could respond with status code other than 401 (Unauthorized), but this actually works against the general HTTP basic auth specification.

Vojtech

[1] http://www.ovirt.org/Features/RESTSessionManagement
[2] http://stackoverflow.com/questions/8008072/how-to-close-or-disable-base-authentication-popup-in-webdriverfirefoxdriver-te
Comment 1 David Botzer 2013-01-13 03:49:56 EST
Created attachment 677644 [details]
auth-popup
Comment 3 Michael Pasternak 2013-02-19 09:13:17 EST
afaics this BZ ain't related to api.
Comment 4 vszocs 2013-02-25 06:21:49 EST
Indeed, WebAdmin's UI Plugins infrastructure tries to acquire REST API session upon successful UI login and pass the session ID to all plugins. This is essentially how REST API support works in UI Plugins.

The problem is web browsers displaying "Authentication Required" popup upon 401 (Unauthorized) response, which *cannot* be prevented with JavaScript/GWT.

From HTTP client perspective, this is perfectly OK. From web application (JavaScript/browser) client perspective, this is problematic.

@David, do you think we should acquire REST API session only under certain condition (e.g. configuration value)?

@Michael, is there anything you would suggest with regard to 401 response handling in web clients (browsers)?
Comment 5 Einav Cohen 2013-02-26 12:16:26 EST
Vojtech: 

- why are we getting the "Authentication Required" response in the first place? is something wrong with the way we attempt to acquire a REST API session and/or with the heartbeat mechanism? this is what should really be investigated.

- not sure if we already have this or not: maybe we should have a global configuration value for enabling/disabling ui plugins (in case there is a "disaster" in one or more of the existing plugins?)

[I am not sure about acquiring REST API session in ui-plugins according to configuration value, as this can ruin the behavior for some (or all) the existing ui-plugins]
Comment 6 vszocs 2013-03-04 10:26:12 EST
> why are we getting the "Authentication Required" response in the first place?

Good question. WebAdmin tries to acquire REST API session using UI login credentials, so it would mean:
(a) user IS able to log into WebAdmin with given credentials
(b) user IS NOT able to call REST API with given credentials

I was under impression that (a) success always implies (b) success.

> is something wrong with the way we attempt to acquire a REST API session and/or with the heartbeat mechanism? this is what should really be investigated.

Indeed, we should investigate. However, the implementation in WebAdmin generally follows instructions in [http://wiki.ovirt.org/Features/RESTSessionManagement], so it's strange why it works in some cases, and doesn't work in other cases.

> not sure if we already have this or not: maybe we should have a global configuration value for enabling/disabling ui plugins (in case there is a "disaster" in one or more of the existing plugins?)

No, currently we can only disable plugins on per-plugin basis (modifying plugin user configuration file).

I agree with your point, there should be a way to enable/disable UI plugins globally via Engine configuration.

> [I am not sure about acquiring REST API session in ui-plugins according to configuration value, as this can ruin the behavior for some (or all) the existing ui-plugins]

Right, it was just an idea :)
Comment 14 vszocs 2013-05-06 10:05:48 EDT
Upstream patch merged, proceeding with downstream backport/ack/merge process.
Comment 17 David Botzer 2013-05-16 09:56:13 EDT
Fixed,3.2/SF17
I added AD, and was able to authenticate,
After I blocked the AD server I verified its blocked,
And could not connect, Then I saw no Popup window was displaying
Fixed,3.2/SF17
Comment 21 Itamar Heim 2013-06-11 04:22:17 EDT
3.2 has been released
Comment 22 Itamar Heim 2013-06-11 04:24:40 EDT
3.2 has been released

Note You need to log in before you can comment on or make changes to this bug.