Bug 1112404

Summary: [AAA] UX SSO fixups
Product: [Retired] oVirt Reporter: Alon Bar-Lev <alonbl>
Component: ovirt-engine-webadminAssignee: Alexander Wels <awels>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Belka <jbelka>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: awels, bazulay, bugs, djasa, ecohen, gklein, iheim, juwu, mgoldboi, rbalakri, vszocs, yeylon, yzaslavs
Target Milestone: ---Keywords: CodeChange
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: ux
Fixed In Version: vt3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-17 12:24:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: UX RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1113937    

Description Alon Bar-Lev 2014-06-23 21:12:16 UTC
Some unclosed edges when SSO is used with our product. We can have trivial solution until we attend bug#1037699.

1. 401 status should go to login page.

2. at login page call a query that receives authentication status, if authenticated just refresh so autologin will be invoked.

3. if we find XSRF mismatch we can redirect to login page, this can be done by a query or adding a header with a code to the 500 response.

I suggest to do this for 3.5.0, so we can support SSO properly as technology preview.

Comment 1 Alon Bar-Lev 2014-06-25 15:24:15 UTC
a solution to (3):

Author: Alexander Wels <awels>
Date:   Wed Jun 25 09:10:57 2014 -0400

    userportal,webadmin: clear token on error
    
    - Added code to clear the token on the client and
      reacquire it when retrying the attempt that errored out. This
      is to support scenarios where the token might have changed
      without the client knowing.
    
    Change-Id: I66c08d021788ebee561d39907f06de22cfe77b22
    Signed-off-by: Alexander Wels <awels>

Comment 2 Alon Bar-Lev 2014-06-25 23:23:14 UTC
When using gwt-rpc, for some reason every request is performed anonymously, gets 401 and repeated with authorization headers. It is as if the state is not kept between requests.

Comment 3 Alexander Wels 2014-08-05 12:55:14 UTC
It is not just GWT-RPC, it is every request made that does the following sequence:
1. Make request without auth info.
2. Receive 401 from server.
3. Re-send request with auth info.
4. Receive 200 from server.

It does this for the host page, css, image, GWT-RPC calls, everything. After doing extensive research it turns out this is expected behavior for most browser and server combinations. According to RFC 4559 [1] the auth sequence above is to be used per request not per session.


[1] http://tools.ietf.org/html/rfc4559

Comment 4 Jiri Belka 2014-09-17 09:33:02 UTC
CodeChange only or is it easy for a verification? If the latter please provide steps for verification. Thx.

Comment 5 Alon Bar-Lev 2014-09-17 09:37:30 UTC
(In reply to Jiri Belka from comment #4)
> CodeChange only or is it easy for a verification? If the latter please
> provide steps for verification. Thx.

it actually should be verified with bug#1113937, if it is ok, then no issues here.

Comment 6 Jiri Belka 2014-09-17 10:01:48 UTC
ok based on #5.

Comment 7 Sandro Bonazzola 2014-10-17 12:24:53 UTC
oVirt 3.5 has been released and should include the fix for this issue.

Comment 8 Alon Bar-Lev 2015-07-30 07:08:07 UTC
*** Bug 1248087 has been marked as a duplicate of this bug. ***

Comment 9 Alon Bar-Lev 2015-07-30 09:59:47 UTC
*** Bug 1248087 has been marked as a duplicate of this bug. ***