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
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