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.
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>
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.
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
CodeChange only or is it easy for a verification? If the latter please provide steps for verification. Thx.
(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.
ok based on #5.
oVirt 3.5 has been released and should include the fix for this issue.
*** Bug 1248087 has been marked as a duplicate of this bug. ***