Bug 894687
Summary: | [rhevm] - Webadmin - Web Admin tries to acquire REST API session using UI user credentials ("Authentication Required" browser popup) | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | David Botzer <dbotzer> | ||||
Component: | ovirt-engine-webadmin-portal | Assignee: | Vojtech Szocs <vszocs> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | David Botzer <dbotzer> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 3.2.0 | CC: | acathrow, bazulay, chetan, cmorriss, dyasny, ecohen, iheim, mpastern, oramraz, pstehlik, Rhev-m-bugs, sgrinber, ykaul, yzaslavs | ||||
Target Milestone: | --- | Keywords: | Regression | ||||
Target Release: | 3.2.0 | Flags: | sgrinber:
Triaged+
|
||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | ux | ||||||
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: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 948448 | ||||||
Attachments: |
|
Description
David Botzer
2013-01-13 08:22:51 UTC
Created attachment 677644 [details]
auth-popup
afaics this BZ ain't related to api. 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)? 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] > 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 :) Upstream patch merged, proceeding with downstream backport/ack/merge process. 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 3.2 has been released 3.2 has been released |