Bug 1161734

Summary:	Double backend login during frontend login
Product:	[Retired] oVirt	Reporter:	Alon Bar-Lev <alonbl>
Component:	ovirt-engine-webadmin	Assignee:	Vojtech Szocs <vszocs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ondra Machacek <omachace>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.3	CC:	alonbl, bugs, ecohen, gklein, iheim, lsurette, mgoldboi, rbalakri, s.kieske, yeylon
Target Milestone:	---
Target Release:	3.5.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	ux
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-01-21 16:06:22 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-11-07 18:04:10 UTC

In 3.5.0 there is double login into application:
1. backend
2. restapi

This result in double delay when login, we already had many bugs opened because of login performance when user is using ldap and many groups.

We tried to improve this greatly in 3.5, however because of the double login it won't be visible or even worse.

Options to solve this in 3.5 should be applied:
1. use ovirt-engine/webadmin/api to redirect into api.
2. add query to return the engine session id, and add a internal private header to restapi to accept context.
3. retrieve session if using ssl.

Anything to avoid double login, even temporary solutions that are to be removed in 3.6.

Comment 1 Alon Bar-Lev 2014-11-12 07:09:05 UTC

actually since 3.2.2

Comment 2 Alon Bar-Lev 2014-11-24 13:45:39 UTC

BTW: this also solved SSO into the application, as the unexpected assumption of reusing password would have caused application not to work within SSO environment in which password is not available to application.

Comment 3 Ondra Machacek 2014-12-17 13:49:36 UTC

...
Accept-Language	en-US,en;q=0.5
Authorization	Basic XXXXXXXXXXXXXXXXXXXXXXXXXX
Connection	keep-alive
Cookie	JSESSIONID=P6sJvYVOoQk95pn0l84OwVBI; locale=en_US
DNT	1
Host	10.34.63.31
JSESSIONID	P6sJvYVOoQk95pn0l84OwVBI
Prefer	persistent-auth, csrf-protection
...

is there a reason to still send "Authorization" header?

Comment 4 Alon Bar-Lev 2014-12-17 14:09:53 UTC

(In reply to Ondra Machacek from comment #3)
> is there a reason to still send "Authorization" header?

no. are you sure you invalidated all credentials from your browser instance?

Comment 5 Ondra Machacek 2014-12-17 14:39:45 UTC

aha, after I invalidated it. no "Authorization" header appears.

Comment 6 Vojtech Szocs 2015-01-05 15:27:07 UTC

(In reply to Ondra Machacek from comment #3)
> ...
> Accept-Language	en-US,en;q=0.5
> Authorization	Basic XXXXXXXXXXXXXXXXXXXXXXXXXX
> Connection	keep-alive
> Cookie	JSESSIONID=P6sJvYVOoQk95pn0l84OwVBI; locale=en_US
> DNT	1
> Host	10.34.63.31
> JSESSIONID	P6sJvYVOoQk95pn0l84OwVBI
> Prefer	persistent-auth, csrf-protection
> ...
> 
> is there a reason to still send "Authorization" header?

Sorry for late reply.

The reason why "Authorization" header is still sent is probably due to default web browser behavior - once this header is set, it will aways be sent by the browser alongside request to given target origin. This is also why "Authorization" header is not really appropriate for doing auth stuff in modern web applications.

Comment 7 Sandro Bonazzola 2015-01-21 16:06:22 UTC

oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.