Bug 906046 - Multiple events in the UI about logged in user.
Multiple events in the UI about logged in user.
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
urgent Severity high
: ---
: 3.2.0
Assigned To: vszocs
Pavel Novotny
ux
: Reopened
Depends On:
Blocks: 948448
  Show dependency treegraph
 
Reported: 2013-01-30 12:17 EST by Leonid Natapov
Modified: 2015-09-22 09 EDT (History)
21 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: 2013-02-20 08:25:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
sgrinber: Triaged+


Attachments (Terms of Use)
log (260.87 KB, application/x-gzip)
2013-01-30 12:17 EST, Leonid Natapov
no flags Details


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

  None (edit)
Description Leonid Natapov 2013-01-30 12:17:49 EST
Created attachment 690498 [details]
log

There is flood of events like  "User admin@internal logged in".
Every several seconds  a new event appear. Happens because backend runs  

2013-01-30 19:09:18,026 INFO  [org.ovirt.engine.core.bll.LoginUserCommand] (ajp-/127.0.0.1:8702-10) Running command: LoginUserCommand internal: false

every several seconds.

engine.log attached.
Comment 2 Barak 2013-02-03 05:35:42 EST
Leonid,

from where were the login calls made ?
Webadmin ? UP? API ?
Comment 3 Leonid Natapov 2013-02-03 06:37:32 EST
webadmin
Comment 4 Leonid Natapov 2013-02-20 08:37:01 EST
Ravi,hi !
why did you close this bug as not a bug?
Comment 5 Ravi Nori 2013-02-20 09:08:28 EST
Hi Leonid

To avoid logins/logs, restapi clients should be using persistent-authentication.

This is incorrect usage that is causing the re-authentication of client on the api side resulting in the logs entries.
Comment 6 Michael Pasternak 2013-02-20 09:18:16 EST
Leonid,

We got impression that this logins caused by api working against the same backend
you connected with webadmin to,

please check the connection sources, afaics this is not a bug even if assumption
made above is correct (see Comment 5).
Comment 8 Leonid Natapov 2013-02-21 05:30:33 EST
I am using only Web Admin. No API is working against my RHEVM.
Michael ,you can connect to the host and see what is going on.
leonid-rhevm31.qa.lab.tlv.redhat.com.
Comment 10 Leonid Natapov 2013-02-24 11:24:16 EST
Same user,tried in several browsers. Also checked on Dafna's environment (different RHEVM machine) and she has the same issue. I think it might be better if  someone come and look at the issue instead of rising needinfo flag each time :)
Comment 11 vszocs 2013-02-25 05:32:31 EST
Hi, this is a bug related to UI Plugins infrastructure trying to keep REST API session alive while the user stays authenticated in WebAdmin UI.

RestApiSessionManager (WebAdmin) issues HTTP GET keep-alive request to "/api" every 60 seconds.

> To avoid logins/logs, restapi clients should be using persistent-authentication.
> This is incorrect usage that is causing the re-authentication of client on the api side resulting in the logs entries.

WebAdmin uses persistent-auth scheme as described in http://wiki.ovirt.org/Features/RESTSessionManagement:
* first request (acquire session) is sent with "user@domain:password" credentials + Prefer:persistent-auth [RestApiSessionManager.acquireSession]
* subsequent request (keep session alive) is sent ONLY with REST API JSESSIONID cookie + Prefer:persistent-auth [RestApiSessionManager.scheduleKeepAliveHeartbeat]

Is the above incorrect usage of REST API persistent-auth scheme?

From my perspective, the problem is that each REST API request goes through LoginUserCommand, but I might be missing something.
Comment 12 vszocs 2013-02-25 05:41:43 EST
I tested steps mentioned in Comment 6 to reproduce this issue outside WebAdmin (using ipython interactive shell):

$ import requests

$ r1 = requests.get('http://127.0.0.1:8700/api', auth=('admin@internal', 'xxx'), headers={'Prefer':'persistent-auth'})
-> Engine says: Running command: LoginUserCommand internal: false.

$ r1.cookies
-> JSESSIONID cookie value received.

$ r2 = requests.get('http://127.0.0.1:8700/api', cookies=dict(JSESSIONID='Xg8zfn1FvdNHEsRFRn0U5I+l.undefined'), headers={'Prefer':'persistent-auth'})
-> No LoginUserCommand in Engine log.

So it's definitely a bug in WebAdmin.
Comment 13 vszocs 2013-02-25 05:43:33 EST
> I tested steps mentioned in Comment 6 ...

Should be Comment 11
Comment 18 vszocs 2013-04-12 16:27:34 EDT
The root cause of this issue seems to be WebAdmin/browser passing HTTP Basic Auth header ("Authorization":"user@domain:password") within the keep-alive heartbeat request, along with JSESSIONID cookie + "Prefer":"persistent-auth" header.

Using ipython interactive shell to reproduce this issue outside WebAdmin:

$ r2 = requests.get('http://127.0.0.1:8700/api', cookies=dict(JSESSIONID='zzz'), headers={'Prefer':'persistent-auth'}, auth=('admin@internal', 'xxx'))
-> Engine says: Running command: LoginUserCommand internal: false.
-> This means new REST API session is created on each heartbeat request, with new session ID passed via Set-Cookie response header.

REST API apparently treats HTTP Basic Auth header with higher priority than "Prefer":"persistent-auth" header, but I assume this is intentional behavior.

So I think there are two possible fixes (I'd really appreciate Michael's feedback here):
A) fix client -> prevent browser sending HTTP Basic Auth header past initial session acquiry request
B) fix server -> treat "Prefer":"persistent-auth" header with higher priority than HTTP Basic Auth header

I suggest option B) mainly because persistent sessions is a feature implemented on top of authentication in REST API, and not the opposite way. In the meantime, I'll be working on option A).
Comment 19 vszocs 2013-04-12 16:48:51 EDT
It seems that even though WebAdmin (JavaScript) doesn't set Authorization header for heartbeat request, web browser is still setting it (using value from initial session acquiry request) before dispatching the heartbeat request.

I'll try to work around this, but I highly recommend to consider option B) mentioned in comment #18. In other words, WebAdmin (JavaScript) doesn't have full control over HTTP request processing, unlike traditional HTTP client, so hopefully REST API provides a helping hand here.
Comment 20 vszocs 2013-04-12 17:01:02 EDT
[1] confirms that once web browser sends request with HTTP Authorization header, all subsequent requests for given origin will include this Authorization header (e.g. it cannot be removed via JavaScript). This is standard browser behavior that cannot be changed with JavaScript.

[1] http://stackoverflow.com/questions/7786574/how-to-remove-authorization-basic-usernamepassword-header-from-browser
Comment 21 Michael Pasternak 2013-04-14 04:01:08 EDT
(In reply to comment #18)
> The root cause of this issue seems to be WebAdmin/browser passing HTTP Basic
> Auth header ("Authorization":"user@domain:password") within the keep-alive
> heartbeat request, along with JSESSIONID cookie + "Prefer":"persistent-auth"
> header.
> 
> Using ipython interactive shell to reproduce this issue outside WebAdmin:
> 
> $ r2 = requests.get('http://127.0.0.1:8700/api',
> cookies=dict(JSESSIONID='zzz'), headers={'Prefer':'persistent-auth'},
> auth=('admin@internal', 'xxx'))
> -> Engine says: Running command: LoginUserCommand internal: false.
> -> This means new REST API session is created on each heartbeat request,
> with new session ID passed via Set-Cookie response header.
> 
> REST API apparently treats HTTP Basic Auth header with higher priority than
> "Prefer":"persistent-auth" header, but I assume this is intentional behavior.
> 

Auth + Prefer headers used to initiate authentication session, once client
obtains the session, he should *not* send Auth header (unless he wish to
re-initialise the session (what will trigger engine login using Auth h. params))
Comment 28 vszocs 2013-05-06 10:05:53 EDT
Upstream patch merged, proceeding with downstream backport/ack/merge process.
Comment 29 vszocs 2013-05-06 11:01:41 EDT
Note regarding the above mentioned patch: after applying, there will be two "User <username@domain> logged in." business events for each user login: first one due to WebAdmin GUI user login, second one due to REST API session created with GUI user credentials.
Comment 32 Pavel Novotny 2013-05-15 10:49:45 EDT
Verified in rhevm-3.2.0-10.26.rc.el6ev (sf17).

After login into webadmin as user admin@internal, there are only two events "User admin@internal logged in." listed as mentioned in comment #29. 

According to BZ release notes ("Doc Text" field), no subsequent login events are then reported, because no keep-alive requests are being made. Instead, a session timeout is set via HTTP header "Session-TTL: 360".
Comment 33 Itamar Heim 2013-06-11 04:38:20 EDT
3.2 has been released
Comment 34 Itamar Heim 2013-06-11 04:38:20 EDT
3.2 has been released
Comment 35 Itamar Heim 2013-06-11 04:38:32 EDT
3.2 has been released
Comment 36 Itamar Heim 2013-06-11 04:46:20 EDT
3.2 has been released

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