Bug 958861

adding reference to the first e-mail in the related engine-devel thread:
http://lists.ovirt.org/pipermail/engine-devel/2013-April/004235.html

@Michael: is there some RFE/document for your "URI based authentication" proposal?

Assuming user credentials (also possibly JSESSIONID value) could be passed via URI, we could use this as a workaround to avoid dealing with HTTP 'Authorization' header entirely (also possibly to avoid dealing with cookies entirely).

In other words, with "URI based authentication" implemented, we could just skip the 'Custom-Authorization' header entirely (originally proposed for this RFE).

AFAICS, fixing Bug 1007444 solves the issue mentioned here?!, i.e


all you need for session re-initation take place (when old session is expires),
is to keep authorization header in request (what is happens anyway in browsers),
i.e existence of the authorization header in request, does not turn off
session based authentication any more.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1007444#c1

This is great news, thanks Michael!

If I understand correctly, when client sends request like this:

  Pass "Authorization" header
  Pass "Prefer:persistent-auth" header
  Pass "Cookie" header with JSESSIONID

Then it should behave like this:

  * if JSESSIONID maps to live (active) session, i.e. `SessionUtils.getCurrentSession(false) != null`, this session won't be re-created (JSESSIONID value stays the same!) but just validated during request processing
  * if JSESSIONID maps to dead (inactive) session, i.e. `SessionUtils.getCurrentSession(false) == null`, new session will be re-created during request processing

If I read patch [http://gerrit.ovirt.org/#/c/19244/] correctly, "Prefer:persistent-auth" header must be specified in order to attempt to re-use (validate) existing session. This makes much more sense than condition `... && !hasAuthorizationHeader` in Challenger.preProcess method. Session functionality should be tied to "Prefer:persistent-auth" header anyway, since "Authorization" header serves a conceptually different purpose and isn't really related to session functionality.

So the JavaScript client can now just send requests like shown above and extract JSESSIONID either from cookie or "JSESSIONID" response header (the JSESSIONID value might change due to re-creation of dead session) without fear of causing unintentional session re-creation (in case of live session).

Michael is right, if my understanding is correct, it would solve this BZ. Michael, can you please confirm my notes above? (thanks!)

(In reply to vszocs from comment #4)
> This is great news, thanks Michael!
> 
> If I understand correctly, when client sends request like this:
> 
>   Pass "Authorization" header
>   Pass "Prefer:persistent-auth" header
>   Pass "Cookie" header with JSESSIONID
> 
> Then it should behave like this:
> 
>   * if JSESSIONID maps to live (active) session, i.e.
> `SessionUtils.getCurrentSession(false) != null`, this session won't be
> re-created (JSESSIONID value stays the same!) but just validated during
> request processing
>   * if JSESSIONID maps to dead (inactive) session, i.e.
> `SessionUtils.getCurrentSession(false) == null`, new session will be
> re-created during request processing
> 
> If I read patch [http://gerrit.ovirt.org/#/c/19244/] correctly,
> "Prefer:persistent-auth" header must be specified in order to attempt to
> re-use (validate) existing session. This makes much more sense than
> condition `... && !hasAuthorizationHeader` in Challenger.preProcess method.
> Session functionality should be tied to "Prefer:persistent-auth" header
> anyway, since "Authorization" header serves a conceptually different purpose
> and isn't really related to session functionality.
> 
> So the JavaScript client can now just send requests like shown above and
> extract JSESSIONID either from cookie or "JSESSIONID" response header (the
> JSESSIONID value might change due to re-creation of dead session) without
> fear of causing unintentional session re-creation (in case of live session).
> 
> Michael is right, if my understanding is correct, it would solve this BZ.
> Michael, can you please confirm my notes above? (thanks!)

+1

Thanks Michael, I think we can close this BZ now.

Auth info can still be passed via HTTP Authorization header. If the client doesn't have full control over HTTP Authorization header, it can still pass "Prefer:persistent-auth" + "Cookie" header to reuse the session (if it's still active), without fear of causing session re-creation (if the session is still active).

As for passing JSESSIONID value from client to server alongside each request, for a JavaScript-based application running in web browser, the browser should handle the "Cookie" header automatically, as soon as "Set-Cookie" header was detected in a response from server.

So for JavaScript vs. REST API integration:

1. webapp makes initial request ("Authorization" + "Prefer:persistent-auth") and extracts JSESSIONID value from "JSESSIONID" response header (Note: cannot read cookie value due to cookie being set for different path, i.e. "/webadmin" vs. "/api")

2. webapp makes subsequent requests ("Authorization" + "Prefer:persistent-auth") and relies on browser to include "Cookie" header in each request (Note: initial response contained "Set-Cookie" header so browser will send "Cookie" header for each request from now on)

So webapp just needs to check response after each REST API call to see if there's new JSESSIONID value. If the response has "JSESSIONID" header, webapp will use this value if it needs to pass session ID to other systems.