Bug 906046

Leonid,

from where were the login calls made ?
Webadmin ? UP? API ?

webadmin

Ravi,hi !
why did you close this bug as not a bug?

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.

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

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.

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

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.

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.

> I tested steps mentioned in Comment 6 ...

Should be Comment 11

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

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.

[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

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

Upstream patch merged, proceeding with downstream backport/ack/merge process.

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.

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

3.2 has been released

3.2 has been released

3.2 has been released

3.2 has been released